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IV 


EXECUTIVE  SUMMARY 


The  Extensible  Modeling  and  Simulation  Framework  (XMSF)  project  started  in  April  2002  with 
seed  funding  from  the  Defense  Modeling  and  Simulation  Office  (DMSO).  The  effort  kicked  off 
with  a  series  of  workshops  bringing  together  technical  and  program  management  personnel 
across  a  broad  number  of  agencies  and  organizations  to  investigate  the  application  of  web-based 
technologies,  including  the  Extensible  Markup  Eanguage  (XME)  for  data  modeling  and  Web 
services  for  composable  simulation  capabilities,  to  meet  military  modeling  and  simulation 
(M&S)  technical  challenges.  DMSO  continues  to  be  the  principal  sponsor  and  funding  source 
for  the  project;  however,  several  efforts  initially  proposed  or  developed  as  XMSF  exemplars 
have  received  separate  funding  from  various  organizations,  such  as  the  Joint  Forces  Command 
(JFCOM),  the  Defense  Threat  Reduction  Agency  (DTRA),  and  commercial  partners. 

XMSF  is  defined  as  a  composable  set  of  standards,  profiles  and  recommended  practices  for  web- 
based  modeling  and  simulation.  Markup  languages  based  on  XMF,  Internet  technologies,  and 
Web  services  are  combining  to  enable  a  new  generation  of  distributed  M&S  applications  to 
emerge,  develop  and  interoperate.  The  purpose  of  this  task  is  to  develop  the  technical 
framework,  coordinate  with  existing  public  standardization  efforts,  and  demonstrate  distributed 
exemplars  of  the  developed  framework. 

Principal  activities  in  2004  included: 

•  Identification  and  prioritization  of  candidate  standards  for  potential  adoption  by  the  DoD 
M&S  community.  XMSF  partners  have  created  strong  technical  relationships  with 
several  key  standards  organizations,  including  the  World  Wide  Web  Consortium  (W3C), 
the  Object  Management  Group  (OMG),  the  Open  Geospatial  Consortium  (OGC),  the 
Simulation  Interoperability  and  Standards  Organization  (SISO),  the  Web3D  Consortium, 
the  Internet  Engineering  Task  Force  (IETF),  the  Web-enabled  Simulation  Consortium 
(WebSim),  and  the  High  Fevel  Architecture  (HFA)  Technical  Support  Team. 

•  Preparation  and  conduct  of  experiments  to  determine  and  demonstrate  the  applicability  of 
the  candidate  standards  to  meet  the  needs  of  the  DoD  M&S  community.  Efforts 
culminated  in  multiple  demonstrations,  presentations,  and  discussions  at  the  2004 
Interservice/Industry  Training,  Simulation,  and  Education  Conference  (I/ITSEC)  in 
December  2004. 

•  Contribution  to  the  discussions  of  the  future  of  M&S  in  the  Global  Information  Grid 
(GIG)  environment  and  its  M&S  Community  of  Interest  (COI),  by  presentations  of 
related  efforts  and  concepts  during  conferences  and  workshops,  including  the  Simulation 
Interoperability  Workshops,  the  Command  and  Control  Research  and  Technology 
Symposium,  the  NATO  M&S  Conference,  and  a  tutorial  on  this  topic  during  the  I/ITSEC 
2004. 

.  Creation  of  an  open  source  prototype  overlay  multicast  system  with  embedded 
performance  monitoring,  capable  of  supporting  typical  distributed  simulation 
performance  over  the  Internet.  The  partners  maintained  a  laboratory  capability  to  support 
the  testing  of  this  technology  over  a  wide  area  network. 

•  Refinement  of  the  Selectively  Reliable  Multicast  Protocol  (SRMP)  standard  for 
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acceptance  by  the  IETF.  Demonstration  of  overlay  multicast  working  with  SRMP  in 
support  of  distributed  simulation. 

•  Definition  and  prototypical  implementation  of  C2IEDM  based  web  services  for  data 
mediation  and  storage  and  retrieval  in  environments  compatible  to  the  Multilateral 
Interoperability  Programme  (MIP). 

•  Preparation  and  publishing  of  workshop  and  conference  papers,  some  in  refereed 
proceedings  and  refereed  journals,  describing  and  promoting  adoption  of  the  work. 

One  of  the  principal  non-DMSO  funded  XMSF  exemplars  promoted  during  the  year  was  the 
Experimentation  Command  and  Control  Interface  (XC2I).  XC2I  includes  definition  of  an  XML- 
based,  C2-specific  web  services  interest  management  (WSIM)  language.  While  some  aspects  of 
this  language  are  domain  specific  (e.g.,  use  of  order  of  battle  information  for  aggregation  and 
disaggregation),  it  mainly  incorporates  some  new  concepts  such  as  spatial-temporal  filters  that 
further  reduce  data  flow  in  bandwidth-constrained  environments  such  as  the  Internet.  This  effort 
is  comparable  to  the  data  distribution  services  for  the  HLA  Runtime  Infrastructure  but  is  applied 
in  the  general  context  of  service  oriented  architectures.  An  important  result  of  this  work  is 
identification  of  the  need  to  define  a  consistent  approach  combining  Web  services  and  streaming 
multicast  for  high-volume  state  delivery  in  distributed  simulations. 

On  the  basis  of  work  performed  in  2004,  the  following  efforts  are  recommended  for  2005: 

•  Continue  development  of  relationships  with  current  and  additional  standards 
organizations  key  to  widespread  adoption  of  XMSF  concepts  in  the  military  M&S 
community.  Focus  on  continuation  of  the  SISO  XMSF  Profile  Study  Group’s  work  to 
develop  a  profile  standard.  Increase  attention  to  encouraging  new  adopters  to  experiment 
with  XMSF  technologies  and  the  emerging  profile  standard,  and  to  provide  their  lessons 
learned  back  to  the  Profile  SG.  Encourage  experimenters  to  submit  exemplars  to  the 
testbed  to  support  a  virtual  2005  round  up  demo.  In  addition,  the  XMSF  partners  will 
continue  in  leadership/liaison  roles  in  IETF,  OMG  and  Web3D/W3C  including  Web3D 
XMSF  Working  Group;  WebSim,  a  consortium  of  OMG,  Web3D,  SISO,  and  OGC;  and 
SISO  SG. 

.  From  the  management  side,  overlay  multicast  will  need  continued  attention  to  obtain 
standards  body  acceptance.  Current  work  to  employ  XOM  in  a  JFCOM  federation  will 
help  to  build  an  experience  base  for  promotion  of  the  concept;  however,  a  greater  breadth 
of  experience  and  a  continued  involvement  in  the  IETF  standards  process  will  be 
required  for  at  least  one  year  and  possibly  two  years.  This  should  be  pursued  in 
conjunction  with  the  IETF  liaison  role.  From  the  technical  side,  continue  to  refine  the 
SRMP  standard  for  acceptance  by  the  IETF,  based  on  overlay  multicast  working  with 
SRMP  in  support  of  distributed  simulation.  Recent  interest  within  Web3D  for  use  of 
XOM  can  help  to  build  this  case. 

•  Complete  integration  of  a  web  enabled  IEEE  1516  RTI  into  an  overlay  multicast  network 
environment  (using  2004  funding  not  yet  on  contract).  Expand  this  to  a  compelling 
demonstration  using  the  Xj3D  viewer  and/or  the  latest  version  of  the  JFCOM  web 
viewer. 

•  Continue  to  infonn  the  M&S  community  through  conference  and  workshop  participation 
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in  the  form  of  technical  papers,  online  and  live  tutorials,  and  presentations. 

•  Develop  a  proposed  approach  to  multicasting  that  is  compatible  with  Web  services. 
Extend  the  work  into  the  emerging  publish-subscribe  Web  technologies  and  standards. 
Promote  the  streaming  standard  and  XML  compression  techniques  that  are  its  natural 
companion,  allowing  high-perfonnance  tagged  streams  of  data  to  be  passed  across 
simulations  and  C4I  systems. 

•  Focus  the  XMSF  Distributed  Testbed  in  2005  on  experiments  in  use  of  a  pilot  registry  for 
semantic  interoperation  of  existing  simulation  and  C4I  software.  This  process  will  yield 
essential  understanding  of  support  for  composability  and  also  will  help  to  advise  the 
ongoing  process  of  assembling  the  M&S  Namespace.  The  partners  will  provide  focused 
leadership  and  participate  in  development  to  detennine  an  initial,  minimal  set  of  metadata 
tags,  to  experiment  with  tools  and  supporting  algorithms  that  would  use  the  metadata  tags 
on  components  in  a  registry  to  find  suitable  components,  and  to  align  data  models  via 
technologies  such  as  XSLT. 

.  Extend  WSIM  work  from  XC2I  to  create  a  general  purpose  web  services  interest 

management  language.  This  language  will  be  mappable  to  IEEE  1516  Data  Distribution 
Management  (DDM).  An  open-source  test  implementation  and  its  source  code  will  be 
hosted  in  the  testbed,  in  a  manner  compatible  with  Overlay  Multicast  and  XMSF 
Registries. 

•  Transform  the  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  into 
three  XML  based  versions  (logical  data  model,  physical  data  model,  documentation)  and 
map  the  IDEF1X  extension  rules  to  XML  extension  rules.  Conduct  two  invited  expert 
workshops  to  conduct  this  task  and  present  the  results  to  the  community.  Provide  an 
exemplar  C2IEDM  tactical  application  (e.g.,  TOPTIVA  from  the  Naval  Undersea 
Warfare  Center)  and  examine  strategies  for  a  C2IEDM  Semantic  Web  service. 

•  Distribute  the  C2IEDM  web  services  for  data  mediation  and  data  storage  and  retrieval 
within  the  international  military  M&S  community  as  a  basis  for  common  and  aligned 
design  of  application  and  extension  rules.  This  operational  international  effort  should  be 
aligned  with  the  C2IEDM  Semantic  Web  service  efforts. 

•  Continue  management  and  enhancement  of  an  XMSF  distributed  testbed  for  distributed 
proof-of-principle  and  technology  demonstrations.  The  focus  is  on  providing  continuous 
availability  of  Web  services/servers  supporting  broad  experimentation  with  XMSF 
profiles. 

•  Through  articles  and  papers,  show  the  potential  of  software  engineering  concepts,  such  as 
the  Model  Driven  Architecture  (MDA),  to  compose  simulations  in  a  System  of  Systems 
Environment  applicable  to  global  grids,  the  Global  Information  Grid  (GIG),  and  other 
service  oriented  environments. 

•  Create  an  exemplar  design  in  the  domain  of  executable  architectures  to  show 
applicability  to  XMSF  of  this  emerging  field. 

.  Continue  to  coordinate  efforts  with  DMSO  through  frequent  technical  and  management 
interactions  and  periodic  progress  reporting. 

Overall,  the  project  continues  to  make  exceptional  progress  in  promoting  web-based  concepts  to 
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the  military  M&S  community  as  witnessed  by  the  increasing  number  of  papers,  activities,  and 
program  concepts  at  DMSO  and  other  agencies,  such  as  JFCOM  and  DTRA,  employing  these 
concepts. 
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1  INTRODUCTION 


1.1  Background 

The  Extensible  Modeling  and  Simulation  Framework  (XMSF)  is  a  composable  set  of  standards, 
profiles  and  recommended  practices  for  web-based  modeling  and  simulation.  Markup  languages 
based  on  XMF,  Internet  technologies,  and  Web  services  will  enable  a  new  generation  of 
distributed  modeling  and  simulation  applications  to  emerge,  develop  and  interoperate.  The 
purpose  of  this  task  is  to  develop  the  technical  framework,  coordinate  with  existing  public 
standardization  efforts,  and  demonstrate  distributed  exemplars  of  the  developed  framework. 

The  XMSF  project  started  in  April  2002  with  seed  funding  from  the  Defense  Modeling  and 
Simulation  Office  (DMSO).  The  effort  kicked  off  with  a  series  of  workshops  bringing  together 
technical  and  program  management  personnel  across  a  broad  number  of  agencies  and 
organizations.  The  findings  of  the  initial  workshops  are  documented  in  (Brutzman,  et.  ah,  2002). 
DMSO  continues  to  be  the  principal  sponsor  and  funding  source  for  the  project;  however, 
several  efforts  initially  proposed  or  developed  as  XMSF  exemplars  have  received  separate 
funding  from  various  organizations,  such  as  the  Joint  Forces  Command  (JFCOM)  and  the 
Defense  Threat  Reduction  Agency  (DTRA). 

The  XMSF  project  team  consists  of  academic  and  corporate  partners;  specifically:  the  Naval 
Postgraduate  School  (NPS)  Modeling,  Virtual  Environments  and  Simulation  (MOVES)  Institute; 
George  Mason  University  (GMU);  Science  Applications  International  Corporation  (SAIC);  Old 
Dominion  University  (ODU)  Virginia  Modeling,  Analysis,  and  Simulation  Center  (VMASC). 

1.2  Objective 

Specific  requirements  from  the  project  Statement  of  Work  (SOW)  for  2004  are  stated  below: 

•  Start  of  Work  teleconference,  to  be  scheduled  by  the  Contractor  as  mutually  agreed  with 
the  Contracting  Agency’s  Contracting  Officer’s  Representative  (COR)  and  DMSO. 

o  The  purpose  of  the  conference  is  to  ensure  a  complete  understanding  of  the 
requirements  by  both  the  Government  and  the  Contractor. 

o  As  part  of  the  conference,  the  contractor  shall  provide  a  chart  depicting  their 
projection  of  the  expenditure  of  the  available  funding  over  the  period  of 
performance  of  the  project. 

o  The  projection  is  for  planning  purposes  only  and  will  not  be  used  to  control  the 
execution  of  the  work. 

o  Prepare  and  deliver  minutes  of  the  start  of  work  teleconference. 

•  Prepare  a  Monthly  Financial  Status  and  Progress  Report.  This  report  shall  summarize 
work  accomplished  during  each  reporting  period,  to  include: 

o  The  results  of  In  Progress  Reviews  (IPRs)  and  meetings 

o  Resources  consumed  to  accomplish  the  work  (labor  hours  by  category  and  total 
cost,  travel  and  costs,  and  other  direct  costs) 

o  Work  planned  for  the  next  reporting  period  and  an  estimate  of  resources  required 
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to  accomplish  that  work  (detailing  labor  hours  by  category  and  total  cost,  travel 
and  costs,  and  other  direct  costs) 

o  An  overall  status  of  resources,  approved  equipment/materials  procured,  and  status 
of  ah  deliverables. 

o  If  applicable,  highlight  any  potential  issues  with  respect  to  completing  the  work 
as  contracted  (e.g.,  potential  resource  shortfalls,  schedule  slips). 

.  Identify  and  prioritize  a  list  of  candidate  standards  for  potential  adoption  by  the  DoD 
modeling  and  simulation  community. 

o  Include  an  assessment  of  the  utility  of  each  standard  and  the  likelihood  of  it 
meeting  the  needs  of  the  DoD  in  the  short  term  (1-3  years),  mid-term  (4-6  years), 
or  long  tenn  (7+  years). 

o  The  list  shah  identify  the  specific  team  member  responsible  for  each  specific 
standards  effort. 

■  Each  responsible  member  will  provide  DMSO  with  a  report  describing  the 
specific  standard,  its  area  of  applicability  to  the  DoD  M&S  community  to 
include  identification  of  the  standard  or  standards  it  will  replace,  an 
assessment  of  its  maturity  and  required  changes  and  a  timetable  for  the 
adoption  of  those  changes. 

■  Establish  a  liaison  with  the  appropriate  standards  organizations  and 
represent  the  requirements  of  the  DoD  modeling  and  simulation 
community  within  that  organization. 

o  Conduct  experiments  to  detennine  and  demonstrate  the  applicability  of  the 
candidate  standards  to  meet  the  needs  of  the  DoD  modeling  and  simulation 
community. 

o  Demonstrate  the  use  of  the  candidate  standards  in  an  environment  to  be 
coordinated  with  and  approved  by  DMSO. 

■  These  demonstrations  shah  be  designed  to  replicate  the  rigorous  demands 
of  the  DoD  M&S  community. 

■  A  report  of  demonstration  results  shah  be  delivered  within  45  days  of  the 
conclusion  of  the  event  and  shah  contain  a  recommendation  for  or  against 
adoption  of  the  standard  by  the  DoD. 

o  Maintain  liaison  with  the  DoD  High  Level  Architecture  (HLA)  program  and 
provide  representation  to  the  HLA  Technical  Support  Team  and  the  IEEE  1516 
standards  revision  process. 

•  Create  an  open  source  prototype  overlay  multicast  system  with  embedded  performance 
monitoring,  capable  of  supporting  typical  distributed  simulation  performance  over  the 
internet.  Maintain  a  laboratory  capability  to  support  the  testing  of  this  technology  over  a 
wide  area  network. 

•  Continue  to  refine  the  Selectively  Reliable  Multicast  Protocol  (SRMP)  standard  for 
acceptance  by  the  IETF.  Demonstrate  overlay  multicast  working  with  SRMP  in  support 
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of  distributed  simulation. 

•  Integrate  a  web  enabled  IEEE  1516  RTI  into  an  overlay  multicast  network  environment 
using  the  latest  version  of  the  JFCOM  web  viewer. 

.  Produce  conference  papers  in  support  of  the  work. 

In  addition  to  the  core  DMSO  funding,  various  related  projects  funded  by  other  organizations 
contributed  to  the  results  summarized  in  this  report.  The  funding  was  not  limited  to  government 
organizations;  industry  partners  contributed  research  and  development  funds  for  XMSF  efforts 
as  well. 

1.3  Document  Organization 

Chapter  1  of  this  document  provides  an  introduction  to  the  work  tasked  by  DMSO  to  the  XMSF 
project.  Chapter  2  describes  project  management  activities  performed  during  the  year,  including 
technical  reporting  and  task  planning  for  calendar  year  2005.  Financial  data  is  provided  in  a 
separate  limited  distribution  version  of  this  document  (NPS-MV-05-001PR),  controlled  by 
DMSO.  Chapter  3  identifies  candidate  standards  and  standards  bodies  for  engagement  in  the 
XMSF  project.  Chapter  4  addresses  technical  work  performed  on  the  XMSF  Overlay  Multicast 
capability.  Chapter  5  discusses  work  relating  to  the  Web-enabled  Run-Time  Infrastructure  (WE- 
RTI)  and  its  employment  in  the  Experimentation  Command  and  Control  Interface  (XC2I)  project 
funded  by  JFCOM.  Chapter  6  summarizes  efforts  completed  during  the  year  for  community 
education  and  outreach,  including  conference  papers  and  presentations,  tutorials,  workshops,  and 
other  activities.  References  and  a  Glossary  of  Terms  and  Acronyms  are  provided  at  the  end  of 
the  report. 
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2  PROJECT  MANAGMENT 


2.1  Project  Year  2004 

Funding  at  the  start  of  FY04  consisted  of  carry-over  funds  from  FY03  that  had  been  placed  with 
partner  organizations  GMU  and  SAIC,  and  interim  funding  to  NPS  received  at  the  start  of  FY04 
(Oct-Dee  2003)  to  support  activities  through  the  2003  Interservic e/Industry  Training, 

Simulation,  and  Education  Conference  (I/ITSEC).  Primary  FY04  funding  was  received  in 
March  2004. 

Principal  XMSF  funding  was  provided  by  DMSO  to  NPS  for  management  and  distribution  to  the 
partner  organizations  in  March  2004.  While  portions  allocated  to  educational  partners  GMU  and 
ODU/VMASC  were  put  in  place  very  quickly  through  the  Open  Market  Corridor  contracting 
vehicle  (http://www.omchub.com),  the  portion  allocated  to  SAIC  had  to  be  placed  through 
General  Services  Administration  (GSA),  requiring  an  open  competition.  The  funding  has  been 
obligated  to  GSA  since  the  start  of  that  process  (July  2004),  but  the  contract  was  not  awarded  to 
SAIC  until  24  February  2005  creating  serious  delays  in  the  efforts  planned  for  2004. 1  The  end 
date  of  the  contract  to  GMU  has  been  extended  to  allow  some  additional  time  for  coordination  of 
their  effort  with  SAIC’s  efforts  when  the  GSA  contract  is  finally  awarded  (however,  the  contract 
vehicle  limits  the  period  of  perfonnance  to  one  year  from  the  date  of  award  in  May  2004,  so  the 
extension  only  added  two  weeks  to  the  current  effort). 

2.2  Progress  Reporting 

The  following  provides  a  brief  summary  of  the  technical  progress  in  2004  against  the  project 
requirements  delineated  in  Section  1  refer  to  sections  3-6  in  this  document  for  detailed 
information  on  the  work  performed): 

•  Requirement:  Start  of  work  teleconference. 

Action:  Completed  the  requirement  in  weekly  telephone  conferences  in  March/ April 
2004  (minutes  of  all  XMSF  project  meetings  have  been  made  available  through  the 
project  reflector:  xmsf-management@movesinstitute.org).  Prepared  and  delivered  a 
presentation  on  XMSF  Support  to  Long  Term  M&S  Community  Objectives  with  a 
strategy  for  near  term  (FY05)  project  goals  and  funding  requirements. 

•  Requirement:  Monthly  financial  status  reports. 

Action:  Reports  were  prepared  and  delivered  through  November  2004.  Full  financial 
data  is  provided  in  the  companion  limited  distribution  version  of  this  report  (NPS-MV- 
05-00 1PR)  available  through  DMSO. 

•  Requirement:  Prioritized  list  of  candidate  standards  for  potential  adoption  by  the  DoD 
M&S  community.  Also  include  assessment  of  the  standards  utility  and  likelihood  of  it 
meeting  the  needs  of  the  DoD  in  the  short  term  (1-3  years),  mid-term  (4-6  years),  and 
long-term  (7+  years).  The  list  must  identify  the  specific  team  member  responsible  for 
each  specific  standards  effort. 

Action:  Areas  of  standards  development  have  been  identified  and  liaisons  established  - 
refer  to  the  discussion  in  Section  3. 


1  Unfortunately,  the  GSA  contracting  representative  assigned  to  the  work  became  ill  in  December  and  passed  away 
in  late  January.  New  personnel  were  assigned  to  the  paperwork  and  completed  the  processing  as  quickly  as  possible. 


5 


•  Requirement:  Each  team  member  responsible  for  a  specific  standards  effort  must 
provide  DMSO  a  report  describing  the  specific  standard,  its  area  of  applicability  to  the 
DoD  M&S  community  to  include  identification  of  the  standard  or  standards  it  will 
replace,  an  assessment  of  its  maturity  and  required  changes  and  a  timetable  for  the 
adoption  of  those  changes. 

Action:  Refer  to  Section  3  of  this  report. 

•  Requirement:  Demonstrate  the  use  of  the  candidate  standards  in  an  environment  to  be 
coordinated  with  and  approved  by  DMSO. 

Action:  Numerous  demonstrations  were  presented  at  the  2004  I/ITSEC,  including  Web 
services  for  analytical  model  interconnection  and  XC2I  communications,  AUV 
Workbench,  Viskit  graphical  user  interface  for  constructing  discrete  event  simulation 
models,  XMSF  Overlay  Multicast  (XOM)  with  both  IEEE  1516  HLA/RTI  and  Web 
Services  Interest  Management,  X3D  web-based  graphics,  and  others.  This  project 
summary  document  provides  a  description  of  I/ITSEC  activities  to  meet  requirements  for 
a  report  on  demonstration  results  within  45  days  of  the  event.  I/ITSEC  demonstrations 
are  identified  in  Section  3.2. 

•  Requirement:  Provide  representation  on  the  HLA  Technical  Support  Team  and  as  part 
of  the  HLA  IEEE  1516  standards  revision. 

Action:  SAIC  has  provided  ongoing  representation  for  these  activities,  although  activity 
has  been  hampered  by  contracting  difficulties  in  the  latter  half  of  the  2004  calendar  year. 

•  Requirement:  Develop  and  demonstrate  an  overlay  multicast  network  (XOM)  capable  of 
supporting  actual  simulation  performance  requirements  over  the  Internet.  Maintain  a 
laboratory  capability  to  support  testing  of  this  technology  over  a  wide  area  network. 
Action:  GMU  (including  Denny  Moen’s  dissertation  research)  is  the  lead  organization 
for  development  of  XOM  capabilities.  A  draft  interim  report  on  the  architecture  has 
been  distributed  for  review  and  comment  in  December  2004;  also  refer  to  Section  4  of  the 
present  document.  In  addition  to  the  I/ITSEC  demonstration  described  above,  on  19 
November  2004,  Dr.  Pullen  led  an  online  “deep-dive”  tutorial  presentation  using  the 
Network  EducationWare  (NEW)  collaboration  software  (see  tutorial  announcement 
below).  The  presentation  was  recorded  and  is  available  for  online  viewing.  NPS  (design 
and  prototype  development)  and  SAIC  (demonstration  and  evaluation)  are  contributing  to 
this  effort. 

Overlay  Multicast  and  its  Application  for  Advanced  Distributed  Simulation: 
Growing  demand  for  use  of  Internet/Web-based  services  in  large  scale  real¬ 
time  distributed  virtual  simulation  (RT-DVS)  systems  and  other  real-time 
applications  is  fueling  extensive  interest  in  overlay  multicast  protocols. 

These  applications  demand  Quality  of  Service  (QoS)  and  many-to-many 
multicast  services  that  are  not  available  in  underlying  Internet  services  today 
and  are  not  likely  to  be  offered  as  an  open  network  service  in  the  near 
future.  This  presentation  describes  implementation  of  an  overlay  multicast 
protocol  designed  to  support  many-to-many  multicast  for  RT-DVS 
applications,  called  Extensible  Modeling  and  Simulation  Framework 
Overlay  Multicast  (XOM).  Focus  will  include  the  architecture  and  key 
design  considerations  of  XOM,  as  well  as  preliminary  results  from 
laboratory  experiments  with  our  prototype,  which  will  be  available  for 
download  on  our  website.  Recorded  delivery  via  Network  EducationWare 
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(http://netlab.gmu.edu/xmsf);  click  on  "conference  logon".  To  obtain  an 
account,  send  email  to  help@netlab.gmu.edu 

•  Requirement:  Continue  to  refine  the  Selectively  Reliable  Multicast  Protocol  standard  for 
acceptance  by  the  IETF  (GMU  lead). 

Action:  Internet  Draft  draft-pullen-srmp-05.txt  submitted  by  GMU  is  pending  review  by 
the  IETF  Reliable  Multicast  Working  Group  chair.  Refer  to  the  discussion  in  Section  4. 

•  Requirement:  Integrate  a  web  enabled  IEEE  1516  RTI  into  an  overlay  multicast  network 
environment  using  the  latest  version  of  the  JFCOM  web  viewer  (SAIC  lead).  Refer  to 
the  discussion  in  Section  5. 

Action:  An  initial  capability  was  included  in  the  I/ITSEC  demonstration  described 
above;  however  it  is  our  goal  to  complete  a  more  substantial  demonstration  in  work 
pending  award  of  the  GSA  contract  to  SAIC. 

•  Requirement:  Submit  all  conference  papers  two  weeks  prior  to  the  published  deadline 
for  DMSO  review  and  release  approval. 

Action:  See  Section  6  for  a  listing  of  all  papers,  presentations,  and  tutorials  from  2004 
work  activities. 

2.3  Objective-Driven  Tasking 

In  mid-FY04  the  XMSF  partners  prepared  and  presented  to  DMSO  a  presentation  describing 
XMSF  support  of  long  term  M&S  community  objectives  covering  the  following  topics: 

•  Long  Term  M&S  Community  Objectives 

•  Policy  Impacts  and  Influences 

•  Enabling  Capabilities 
.  FY05  XMSF  Tasking 

The  following  M&S  community  objectives  were  identified: 

.  Broad  DoD  and  Allied  Support 
o  Goal 

■  Recommended  Standards  and  Methods  are  applied  within  the  U.S.  DoD  as  well  as 
in  the  respective  allied  counterparts,  in  particular  NATO 

o  Measures  of  Success 

■  Recommended  Standards  and  Methods  are  incorporated  into  the  Combined  and 
Joint  Operational  Architectures,  such  as  the  Joint  Technical  Architecture  (JTA) 
and/or  NATO  C3  Architecture 

■  Recommended  Standards  and  Methods  are  part  of  the  Code  of  Best  Practices 
applied  in  the  departments 

o  Identify  Stakeholders 

■  U.S.  DoD,  Office  of  the  Secretary  of  Defense  (OSD),  Assistant  Secretary  of 
Defense  National  Information  Infrastructure  (ASD  Nil),  Defense  Information 
Systems  Agency  (DISA),  DMSO,  M&S  Offices  of  the  Services;  NATO 
Consultation,  Command  and  Control  Agency  (NC3A)  (Branches  for  C3I  and 
M&S) 

•  Integrated  IT  Environment  Supporting  the  Warfighter 
o  Goal 

■  Seamless  delivery  of  operationally  required  functionality  within  an  integrated 
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Information  Technology  (IT)  environment  based  on  heterogeneous  components 
o  Measures  of  Success 

■  Number  of  operationally  required  functions  within  repositories 

■  Degree  of  reuse  of  functions  delivered  by  components 

■  Number  of  organizations  participating  in  the  function  sharing  repositories 

■  Seamless  integration  of  M&S  and  C4I  IT 
o  Identify  Stakeholders 

■  DMSO,  DISA,  and  their  counterparts  in  the  services  and  allied  organizations 

•  M&S  Support  of  Military  Operations 
o  Goal 

■  Operational  use  of  M&S  functionality  via  tactical  systems  to  support  all  phases  of 
military  operations,  including  training,  planning,  analysis  of  alternatives, 
rehearsal,  execution,  and  de-briefing  and  evaluation  (after  action  review  and 
analyses) 

o  Measures  of  Success 

■  M&S  functionality  applied  in  tactical/operational  C4I  systems 

■  Degree  of  operationally  required  data  alignment 

■  Degree  of  M&S  functionality  in  the  Mission-to-Means  Framework  (MMF) 
o  Identify  Stakeholders 

■  DMSO,  DISA,  and  counterparts  in  the  services  and  allied  organizations 

•  M&S  Support  of  Life  Cycle  Functions 
o  Goal 

■  Capitalizing  on  M&S  tools  and  technologies  to  deal  with  system  development, 
operational  readiness,  and  life  cycle  cost 

■  This  is  accomplished  through  the  collaborative  efforts  of  the  requirements, 
training,  operations,  and  acquisition  communities,  as  in  the  Army  Simulation, 
Modeling,  Acquisition,  Requirements,  and  Training  (SMART)  Vision 

o  Measures  of  Success 

■  M&S  tools  used  for  all  phases  of  the  life  cycle,  from  requirements  analysis  to 
design,  procurement,  introduction,  operational  use,  to  replacement  and  retirement 

o  Identify  Stakeholders 

■  Acquisition  and  procurement  agencies  and  organizations  of  the  services  and 
allies,  including  Conference  of  National  Armaments  Directors  (CNAD) 

The  plan  identified  several  potential  policy  impacts  and  influences,  including: 

•  Reference  Models 

•  Meta  Data  and  Meta  Modeling 

•  Open  Standards 

•  Open  Source  versus  Intellectual  Property  (IP)  issues 

•  DoD  Architecture  Framework 

o  Joint  Technical  Architecture 

•  DoD  M&S  Master  Plan 
o  HLA 

•  Net-Centric  Enterprise  Services  (NCES)  &  Global  Information  Grid  (GIG) 

.  JFCOM  J7/J8/J9  policies 

.  Other  CINC  policies  (e.g.  STRATCOM) 
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Allied/coalition  policies 


The  GIG  program  is  organized  around  a  number  of  Communities  of  Interest  (COIs).  The  XMSF 
team  proposed  formation  of  an  M&S  GIG  COI.  The  DoD  M&S  COI  was  officially  established 
by  a  Memo  to  the  Director,  Information  Management,  OASD  (Nil)  from  the  Director  of  the 
Defense  Modeling  &  Simulation  Office  (DMSO)  on  10  June  2004.  The  following  provides 
additional  information  about  progress  in  this  regard: 

•  M&S  COI  for  the  GIG  is  now  in  process  of  formation 
o  High-level  DMSO-DISA  agreement 

o  Namespace  is  critical  to  effective  XMSF  deployment 

•  Opportunity  to  create  effective  C4I-Simulation  links  in  DISA’s  Network  Centric  Capabilities 
Pilot  (NCCP) 

o  ASD(NII)  program  to  demonstrate  breaking  down  stovepipes 
o  Displays  C4I  best-of-breed  Web  services 
o  Opportunity  to  show  effectiveness  of  M&S  Web  services 
.  XMSF  HF  goals: 

o  August  04:  provide  context  for  simulation  such  as  JFCOM’s  Joint  Urban  Operations  with 
an  early  XC2I  prototype 

o  August  05:  operate  XBML  and  XC2I  using  real  C4I  system  feeds 

•  Affects  long  term  community  objective 

o  Integrated  C4I  environment  with  simulation  tools  supporting  military  operations 

To  achieve  objectives  of  the  XMSF  program,  a  number  of  enabling  capabilities  must  be 
established  or  solidified,  including: 

•  Simulation  Interoperability  Support 
o  Supporting  Technologies 

■  XMSF  core  technologies: 

■  XML,  Simple  Object  Access  Protocol  (SOAP),  Hyper  Text  Transfer 
Protocol  (HTTP),  Internet  Protocol 

■  Registries  and  repositories 

■  M&S  namespace,  Web  Services  Description  Language  (WSDL),  Business 
Process  Execution  Language  for  Web  Services  (BPEL4WS),  Web 
Ontology  Language  (OWL) 

■  Composability  support 

■  Metadata,  Conceptual  modeling  language 

■  Currently  deployed  frameworks  and  technologies 

■  Test  and  Training  Enabling  Architecture  (TENA)  (HLA  &  others), 
Distributed  Continuous  Experimentation  Environment  (DCEE)  (HLA  & 
DIS),  Joint  National  Training  Center  (JNTC)  (HLA  &  DIS),  Web-Enabled 
Run-Time  Infrastructure  (WE  RTI) 

o  Supporting  Methods 

■  XMSF  Profiles 

■  Concept  of  Operations 

■  Federation  Development  and  Execution  Process  (FEDEP) 

■  Open  standards  and  open  source 

•  Full  Interoperation  of  M&S  and  C4I  Web  Services 
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o  Supporting  Technologies 

■  Common  communication  protocols  enable  physical  connectivity 

■  Common  meta-management  tools  enable  sharing  of  mapping  infonnation 
o  Supporting  Methods 

■  Common  methods  for  metadata  management  (semantic  interoperability) 

■  Common  methods  for  metamodel  management  (pragmatic/dynamic 
interoperability) 

■  Common  conceptual  models/common  concept  of  the  mission  space  (conceptual 
interoperability) 

■  Shared  management  councils/advisors  /standards  bodies 

•  Tactical  Ontologies 

o  Supporting  Technologies 

■  XML,  XML-Schema  for  defining  common  vocabularies 

■  XML  Stylesheet  Language  for  Transformation  (XSLT)  for  language  interchange 

■  Resource  Definition  Framework  (RDF),  RDF  Schemas  (RDF-S),  DARPA  Agent 
Markup  Language  and  Ontology  Inference  Layer  (DAML+OIL),  OWL  and  other 
emerging  Semantic  Web  standards  and  techniques  for  defining  common 
ontologies 

■  Knowledge  Representation 
o  Supporting  Methods 

■  Composability  of  conceptual  models 

■  Levels  of  Conceptual  Interoperability  and  Model-Based  Data  Management 

■  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM)  for  multi¬ 
national  information  interoperability 

■  Extensible  Battle  Management  Language  (XBML)  for  planning  and  operations 
orders 

■  Semantic  Web  Services 

•  Improved  Military  Messaging 
o  Supporting  Technologies 

■  XML  as  a  basis  for  all  messaging 

■  Improved  readability  by  humans,  C4I  systems,  software  agents,  robots 

■  Message  Text  Fonnat  (MTF)  compatibility 

■  Improved  validity,  clarity,  correctness,  interoperability,  and  forward 
compatibility 

■  Compressed  XML  binary  now  providing  smaller  message  size  with  improved 
reliability 

■  Forward  Error  Correction  (FEC)  unlocks  noisy  Radio  Frequency  (RF)  and 
acoustic  communications  links 

■  XML  Tactical  Chat  (XTC) 
o  Supporting  Methods 

■  Formally  register  allowed  vocabularies  in  DoD  registry  to  make  tactical 
ontologies  executable 

•  Viability  of  XML-Based  Technologies 
o  Supporting  Technologies 

■  Long  history  and  application  of  mark-up  languages  (SGML,  HTML) 

■  Broad  and  extensive  industry  adoption 
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■  Growing  numbers  of  software  tools  and  products 

■  Readable  by  human  and  software  agents 

■  Basis  for  next-generation  Semantic  Web 
o  Supporting  Methods 

■  W3C  and  other  powerful  standards  organizations  shaping  the  future  of  the  Web 

■  Foundational  to  all  system  interoperability  developments  today 

■  License-free  and  platform-independent 

•  Common  Ground  Between  Industry  and  Government 
o  Supporting  Technologies 

■  Web/Intemet 

■  Discrete  event  simulation 

■  Computer  graphics/visualization 

■  High  perfonnance  computers/networks 

■  Low-cost  distributed  computers/networks 

■  Wireless  networking 

■  Public  Key  Infrastructure  (PKI)  security 

■  Object-oriented  languages,  especially  Java/C++ 
o  Supporting  Methods 

■  Object-oriented  development 

■  Design  patterns 

■  Rapid  prototyping 

■  Spiral  development 

■  Model  Driven  Architecture  (MDA)  /  Unified  Modeling  Language  (UML) 

•  Agent  Based  Technologies 

o  Supporting  Technologies 

■  Artificial  Intelligence  research 

■  Autonomous  and  cooperating  agents 

■  Planning 

■  Learning 

■  Semi- Automated  Forces 

■  Semantic  Web  (RDF,  DAML+OIL,  OWL) 
o  Supporting  Methods 

■  Standardized  agent  communications  languages 

■  Frameworks  for  mobile  agents(e.g.  CoABS) 

■  Human  behavior  representation 

2.4  FY05  Planning 

Primary  tasks  proposed  for  FY05  are  described  in  the  following  subparagraphs. 

2.4. 1  Overlay  Multicast  Standards 

Background:  In  FY04  GMU  worked  on  an  architecture  for  many-to-many  overlay  multicast  for 
use  with  distributed  simulation  (XOM);  also  working  with  the  IETF  to  have  SRMP  approved  as 
a  draft  standard. 

FY05  work:  Overlay  multicast  will  need  continued  attention  to  obtain  standards  body 
acceptance.  Current  GMU  work  with  SAIC  to  employ  XOM  in  a  JFCOM  federation  will  help  to 
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build  the  experience  base  for  this,  however  a  greater  breadth  of  experience  and  a  continued 
involvement  in  the  IETF  standards  process  will  be  required  for  at  least  one  year  and  possibly  two 
years.  There  is  also  high  potential  for  application  of  XOM  in  the  NCCP.  This  should  be  pursued 
in  addition  to  the  IETF  liaison  role. 

Resources:  .5  Full-Time  Equivalent  (FTE)  faculty  and  one  graduate  student  support  plus  travel  to 
IETF  meetings. 

2.4.2  Streaming  Web  Services 

Background:  A  basic  tenet  of  XMSF  is  the  benefit  of  Web  services  as  a  basis  for  distributed 
software  interoperation.  Web  services  facilitate  interoperation  because  they  are  easy  to  create, 
easy  to  interface,  and  easy  to  compose.  However,  work  for  JFCOM  has  shown  that  the  basic 
SOAP/HTTP  service  requires  30  times  as  much  data  over  the  network  for  unicast  transmission, 
and  the  Web  standards  do  not  provide  for  multicast  (overlay  or  otherwise)  that  could  improve 
network  efficiency  further  by  orders  of  magnitude. 

FY05  work:  GMU  has  proposed  an  approach  to  multicasting  that  is  compatible  with  Web 
services.  An  extension  of  this  approach  into  the  emerging  publish-subscribe  Web  technologies 
and  standards  will  be  required  to  take  advantage  of  our  approach.  GMU  will  promote  the 
streaming  standard;  NPS  will  promote  the  XML  compression  that  is  its  natural  companion, 
allowing  high-perfonnance  tagged  streams. 

Resources:  .5  FTE  faculty  and  2  graduate  students  GMU;  .25  FTE  faculty  and  1  graduate  student 
NPS,  and  travel  to  W3C  meetings. 

2. 4. 3  XMSF  Registries 

Background:  One  of  the  most  promising  aspects  of  XMSF  is  the  support  registries  can  provide 
for  composable  software  processes.  To  date  we  have  not  been  able  to  focus  on  this  promise;  we 
don’t  understand  what  benefits  existing  Web  technology  (UDDI  and  WSDL)  offer  and  what,  if 
any,  additional  capabilities  are  needed  in  Web  standards. 

FY05  work:  Focus  XMSF  Distributed  Testbed  experiments  on  use  of  a  pilot  registry  for 
semantic  interoperation  of  existing  simulation  and  C4I  software.  This  process  will  yield 
essential  understanding  of  support  for  composability  and  also  will  help  to  advise  the  ongoing 
process  of  assembling  the  M&S  Namespace.  SAIC  will  provide  focused  leadership  and 
participate  in  development  to  determine  an  initial,  minimal  set  of  metadata  tags,  experiment  with 
tools  and  supporting  algorithms  that  would  use  the  metadata  tags  on  components  in  a  registry  to 
find  suitable  components,  and  align  their  data  models  via  technologies  such  as  XSLT. 

Resources:  .25  FTE  and  two  graduate  students  each  at  NPS,  ODU,  GMU,  1.75  FTE  at  SAIC. 

2.4.4  Web  Services  Interest  Management  Language 

Background:  In  support  of  XC2I,  SAIC  has  defined  an  XML-based,  C2-specific  web  services 
interest  management  (WSIM)  language.  While  this  language  is  domain  specific,  it  incorporates 
some  new  concepts  such  as  temporal  filters  that  will  further  reduce  data  flow  in  bandwidth 
constrained  environments  such  as  the  Internet. 
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FY05  work:  SAIC  will  extend  previous  work  on  WSIM  from  XC2I  to  a  general  purpose  web 
services  interest  management  language.  This  language  will  be  mappable  to  IEEE  1516  DDM. 
An  open-source  test  implementation  and  its  source  code  will  be  hosted  in  the  testbed,  in  a 
manner  compatible  with  Overlay  Multicast  and  XMSF  Registries. 

Resources:  1  FTE  for  SAIC 

2.4.5  XML  Namespace  and  Mediation  Support 

2.4.5. 1  XML  C2IEDM  Framework 

Background:  The  Command  and  Control  Infonnation  Exchange  Data  Model  (C2IEDM)  is  a 
strong  candidate  for  a  common  information  exchange  model  in  the  military  domain.  At  present 
is  it  captured  using  IDEF1X  models.  The  need  for  an  XML  based  version  has  been  articulated 
repeatedly. 

FY05:  Transfonn  the  C2IEDM  into  three  XML  based  versions  (logical  data  model,  physical  data 
model,  documentation)  and  map  the  IDEF1X  extension  rules  to  XML  extension  rules.  Conduct 
two  invited  expert  workshops  to  conduct  this  task  and  present  the  results  to  the  community. 
Provide  an  exemplar  C2IEDM  tactical  application  (TOPTIVA)  and  examine  strategies  for  a 
C2IEDM  Semantic  Web  service. 

Resources:  .25  FTE  faculty  and  one  graduate  student  support  each  at  ODU  and  NPS  plus  travel 
for  participation  in  international  MIPS  meetings  and  workshops 

2.4. 5.2  XML-Based  Data  Engineering 

Background:  Data  Engineering  consists  of  Data  Administration  (data  resources),  Data 
Management  (meaning  of  data),  Data  Alignment  (target  data  can  be  obtained  from  source  data), 
and  Data  Transformation  (translate  from  source  to  data).  XML  supports  this  already  (Tolk, 
2004),  but  can  be  improved. 

FY05:  Implement  a  tool  set  to  map  one  XML  tag  set  (source)  to  the  C2IEDM  tag  set  (target)  and 
generate  and  XSLT  schema.  Conduct  two  experiments:  (a)  populate  a  target  data  structure  with 
source  data  using  the  XSLT  schema;  (b)  use  a  web  service  based  on  C2IEDM  data  using  source 
data. 

Resources:  .25  FTE  faculty  and  two  graduate  students  support  at  ODU 

2.4.6  XMSF  Distributed  Testbed 

Background:  In  FY03  and  FY04,  ongoing  projects  have  supported  an  initial  set  of  academic 
facilities  for  distributed  proof-of-principle  and  technology  demonstrations. 

FY05  work:  JFCOM  is  evaluating  the  results  of  this  work  for  transition  into  their  operations. 
They  will  not  be  supporting  academic  facilities  for  community  access.  DMSO  should  continue 
some  low-level  support  at  NPS,  ODU,  and  GMU  to  provide  access  for  emerging  technologies  to 
the  M&S  community,  including  the  extension  of  Web  services  to  Grid  Computing  (Grid 
services).  The  focus  is  on  providing  continuous  availability  of  Web  services/servers  supporting 
broad  experimentation  with  XMSF  profiles.  SAIC  has  committed  to  providing  a  high- 
performance  Internet  connection  in  order  to  participate. 
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Resources:  .15  FTE  faculty  and  1  graduate  student  or  technician  at  each  institution,  .15  FTE  at 
SAIC,  $60K  for  four  server  clusters  to  constitute  a  small  experimental  grid. 

2.4. 7  Standards  &  Liaison 

2.4.7. 1  SISO,  IETF,  OMG,  Web3D/W3C,  WebSim 

Background:  The  most  important  process  for  ensuring  XMSF  becomes  an  enabler  of  web 
enabled  M&S  is  its  acceptance  by  the  M&S  community,  which  in  turn  will  require  broadly 
accepted  standards.  This  task  involves  evangelizing  XMSF  to  the  M&S  community  and 
shepherding  the  standards  process. 

FY05  work:  FY  05  tasking  will  focus  on  continuation  of  the  work  by  the  SISO  XMSF  Profile 
Study  Group  (SG)  to  develop  a  profile  standard.  There  will  be  more  focus  on  encouraging  new 
adopters  to  experiment  with  XMSF  technologies  and  the  emerging  profile  standard,  and  to 
provide  their  lessons  learned  back  to  the  Profile  SG.  Experimenters  will  be  encouraged  to 
submit  exemplars  to  the  testbed  to  support  a  virtual  FY  05  round  up  demo.  In  addition,  GMU, 
ODU  and  NPS  have  leadership/liaison  roles  to  IETF,  OMG  and  Web3D/W3C  including  Web3D 
XMSF  Working  Group;  NPS  and  VMASC  have  leadership  for  WebSim,  a  consortium  of  OMG, 
Web3D,  SISO,  and  OGC;  and  SAIC  spearheads  the  SISO  XMSF  Profiles  SG.  OMG  is  of 
particular  interest,  as  they  recently  reestablished  their  M&S  chapter  which  now  explicitly 
focuses  on  Model  Driven  Architecture  (MDA)  approaches  to  enable  web  based  M&S  and 
migration  to  web  and  grid  services.  This  chapter  explicitly  collaborates  with  the  Command  and 
Control  and  the  Homeland  Security  chapters  of  OMG. 

Resources:  .25  FTE  for  each  partner. 

2. 4. 7. 2  MDA  for  XMSF  Management 

Background:  The  OMG  MDA  is  mainly  applied  and  perceived  to  be  a  pure  software  engineering 
tool.  This  view  is  too  limited  and  does  not  pay  the  tribute  to  the  potential  use  of  MDA  for 
management  of  heterogeneous  IT  environments. 

FY05:  ODU  will  show  the  potential  of  the  MDA  to  compose  simulations  in  a  System  of  Systems 
Environment  applicable  to  global  grids,  the  GIG,  and  other  service  oriented  environments  (in 
articles  and  papers). 

Resources:  .25  FTE  faculty  support  at  ODU 
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3  CANDIDATE  STANDARDS 


3.1  Standards,  Standards  Bodies,  and  Liaison  Assignments 

Table  1  identifies  key  standards  areas  that  are  being  investigated  by  the  XMSF  project  team. 
The  table  also  identifies  the  specific  person  responsible  for  investigating,  working  with,  and 
reporting  on  each  area  as  it  relates  to  goals  of  the  XMSF  project. 


Table  1.  Candidate  Standards  and  Assigned  XMSF  Team  Members 


Responsible  Team  Member 
(Standards  Organization(s)) 

Standard(s) 

Time  Frame 
(years) 

Andreas  Tolk 
(SISO,  OMG,  WebSim) 

MDA 

Meta-modeling 

short  (1-3) 
short  (1-3) 

Don  Brutzman 
(Web3D,  W3C,  ISO) 

X3D 

Web  Services 

short  (1-3) 
short  (1-3) 

Mark  Pullen 
(IETF) 

XOM,  SRMP 

short  (1-3) 

Katherine  Morse 
(SISO) 

XMSF  Profiles 

short  (1-3) 

Curtis  Blais 
(W3C) 

Semantic  Web 

short  (1-3) 

In  addition  to  these  areas,  Dr.  Morse,  SAIC,  continues  to  maintain  liaison  with  the  DoD  High 
Level  Architecture  (HLA)  program  and  provides  representation  to  the  HLA  Technical  Support 
Team  and  the  IEEE  1516  standards  revision  process  as  required  by  the  XMSF  project  SOW. 

Dr.  Tolk,  VMASC,  encouraged  the  presentation  to  international  partners,  in  particular  NATO’s 
M&S  Group.  Furthermore,  the  Australian  SimTecT  requested  an  XMSF  workshop  for  2005. 

The  use  of  XMSF  recommendations  within  the  NATO  MSG-027  action  “Pathfinder”  is  currently 
under  consideration. 

3.1.1  Model  Driven  Architecture  and  Other  Meta-Modeling  Standards 

This  section  addresses  investigation  into  the  Model  Driven  Architecture  and  other  meta¬ 
modeling  standards  by  the  XMSF  Partners.  The  material  here  also  appears  in  (Tolk,  2004) 
presented  at  the  2004  Fall  Simulation  Interoperability  Workshop  (SIW). 

3. 1.1.1  Description 

A  metamodel  is  a  precise  definition  of  the  constructs  and  rules  needed  for  creating  semantic 
models  (Metamodel.com,  2004),  which  means  implementation-specific  independent  descriptions 
of  the  underlying  algorithmic  ideas.  Metamodeling  has  been  around  at  least  since  the  late  1980s, 
but  with  the  advent  of  the  Internet  and  business  integration,  process  and  data  integration  have 
gained  importance.  Metamodels  are  the  foundation  for  this  integration.  Metamodels  are  very 
good  at  abstracting  from  lower-level  details  of  integration  and  interoperability,  and  helping  with 
partitioning  problems  into  orthogonal  sub-problems.  The  enterprise  architecture  components 
and  the  products  of  the  DoD  Architecture  Framework  (DoDAF)  are  actually  examples  for 
metamodels.  UML  in  general,  and  specialized  subsets  such  as  the  Meta-Object  Facility  (MOF) 
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and  the  Common  Warehouse  Metamodel  (CWM)  in  particular,  are  languages  for  metamodeling. 
The  common  idea  behind  this  is  abstraction  or  generalization  to  discover  common  challenges 
and  solutions.  Metamodeling  helps  to  show  this  common  ground,  to  make  separate  communities 
aware  that  they  are  actually  working  on  the  same  problem  and,  by  doing  so,  avoiding  double 
work  and  enabling  reuse.  Furthennore,  interoperability  and  composability  as  required  in  (Davis 
and  Anderson,  2003)  become  feasible.  The  use  of  a  common  methodology  to  express  these 
metamodels  enables  the  establishment  of  enterprise  architecture  hierarchies  comprising 
composable  solutions. 

The  Object  Management  Group  (OMG)  uses  the  concept  of  metamodels  extensively  (Sprinkle, 
et.  al.,  2001).  Generally,  metamodeling  is  the  process  of  designing  systems  and  applications 
through  meta  and  meta-meta  notations.  The  use  of  models  and  translation  patterns  between 
models  ensures  syntactic  and  semantic  consistency.  Four  layers  are  defined: 

•  The  User  Object  Layer  contains  the  information  to  be  described,  which  comprises  the  objects 
of  the  application;  in  other  words,  real  classes,  functions,  and  data  being  implemented. 

•  The  Model  Layer  contains  metadata  describing  the  information  in  the  User  Object  Layer. 
This  model  is  the  first  abstraction  layer. 

•  The  Metamodel  Layer  describes  and  defines  the  structure  and  semantics  of  meta-data  in  the 
Model  Layer.  UML  for  representing  processes  or  XML  for  representing  data  are  typical 
metamodels. 

•  Finally,  the  Meta-Metamodel  Layer  contains  description  of  the  structure  and  semantics  of 
meta-models. 

Table  2  summarizes  the  layers  and  gives  an  example  of  each  layer.  Note  that  this  architecture 
focuses  on  syntax. 


Table  2.  Four-Layer  Metamodeling  Architecture 


Layer 

Description 

Example 

Meta- 

Metamodel 

Defines  the  language  for  specifying 
metamodels. 

MetaClass,  MetaAttribute, 
MetaOperation 

Metamodel 

Defines  the  language  for  specifying  a 
model. 

Class,  Attribute,  Operation, 
Component 

Model 

Defines  a  language  to  describe  an 
information  domain. 

Tank,  Caliber,  openFire,  Turret 

User  Objects 
User  Data 

Defines  a  specific  information  domain. 

M1A1,  50,  Fire,  T156 

It  is  likely  that  we  will  observe  the  same  discussions  concerning  metamodels  we  are  actually 
seeing  in  the  standards  domain;  that  is,  should  a  metamodel  be  widely  applicable  or  custom 
tailored  to  support  a  given  domain  more  efficiently?  As  with  standard  solutions  it  is  often 
necessary  to  trade  domain  efficiency  for  broader  interoperability.  However,  we  believe  that 
more  general  metamodels  can  be  used  to  support  interoperability  even  between  highly 
specialized  solutions  on  the  implementation  level.  In  other  words,  while  performance  and 
domain-tailored  solutions  should  be  supported  on  the  implementation  level,  broader  applicability 
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must  be  the  focus  on  the  metamodel  level. 


Metamodels  and  the  Model  Driven  Architecture.  There  is  no  generally  accepted  method 
supporting  metamodeling.  However,  one  of  the  most  widespread  approaches  is  the  use  of  UML 
to  describe  metamodels.  Standardized  by  OMG  in  1997,  UML  has  gained  interest  from 
management  consulting  Finns,  business  analysts,  system  analysts,  software  developers,  and 
programmers.  It  can  be  seen  as  the  standard  for  blueprints  of  software  solutions.  Recently, 
however,  the  OMG  community  has  taken  this  a  step  further  through  introduction  of  the  Model 
Driven  Architecture  (MDA)  (OMG,  2004).  MDA  merges  the  different  OMG  standards 
previously  developed  and  used  separately  into  a  common  view  by  applying  common 
metamodels.  The  key  idea  of  MDA  is  to  use  a  common  stable  model,  which  is  language-, 
vendor-  and  middleware -neutral.  This  is  a  metamodel  of  the  concept.  With  such  a  model  in  the 
center,  users  having  adopted  the  MDA  gain  the  ability  to  derive  code  for  various  sub-levels. 

Even  if  the  underlying  infrastructure  shifts  over  time,  the  metamodel  remains  stable  and  can  be 
ported  to  various  middleware  implementations  as  well  as  platforms.  To  be  able  to  do  so,  the 
MDA  defines  an  approach  that  separates  the  specification  of  the  system  functionality  (Platform 
Independent  Model,  or  PIM)  from  the  specification  of  the  platform  specific  implementation 
(Platform  Specific  Model,  or  PSM),  and  the  capability  to  transform  the  PIM  into  a  PSM. 

Distinguishing  between  needed  functionality  and  platform  specific  implementation  conforms  to 
the  ideas  of  the  DoDAF;  namely,  distinguishing  the  operational  architecture  view  and  the  system 
architecture.  In  addition,  the  mapping  of  DoDAF  products  to  UML  diagrams  and  vice  versa 
supports  the  mutual  application  of  the  methods,  which  adds  commercial  expertise  and  support  to 
DoDAF,  and  military  expertise  and  operational  relevance  to  UML  products.  DoDAF/UML  has 
the  potential  to  become  a  core  model  for  the  military  PIM,  a  metamodel  for  military  operations. 

Another  aspect  of  the  MDA  seldom  mentioned  is  management.  Similar  patterns  as  those  used  to 
map  PIM  to  PSM  can  be  used  to  support  reverse  engineering.  Every  M&S  service  or  component 
should  be  delivered  with  a  PIM  describing  what  parts  of  the  operationally  defined  and  required 
functionality  is  implemented.  This  allows  gradual  definition  of  the  covered  mission  space  based 
on  heterogeneous  and  distributed  components. 

Metamodel  Frameworks  and  Mappings.  The  metamodel  for  services  identifies  functionality 
to  find  services,  to  evaluate  those  services  for  applicability,  to  prepare  and  transfer  input  data,  to 
invoke  the  service(s),  to  receive  results,  and  finally  to  perfonn  any  necessary  “clean  up.”  The 
web  service  stack  (Figure  1)  categorizes  the  supporting  standards  in  a  set  of  layers:  transport, 
messaging,  description,  quality  of  experience,  and  service  composition.  Which  standards  are 
chosen  to  deliver  the  functionality  is  interchangeable  and  mainly  driven  by  the  overall  system 
constraints. 
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Figure  1.  Web  Services  Stack 


Generally,  metamodels  will  help  to  migrate  solutions  (e.g.,  from  USMTF  to  XML)  or  to  adapt 
standardized  solutions  for  special  purposes  (e.g.,  mapping  XML  based  information  to  binary 
codes  for  a  special  radio  link).  If  the  idea  of  PIM  and  PSM  is  used,  some  mappings  can  be  auto¬ 
generated  based  on  industry  standards.  Furthermore,  the  mapping  must  be  extended  to  upper 
levels  (business  processes  supported)  and  lower  levels  (network  protocols  used)  to  complete  the 
picture.  An  ongoing  discussion  is  whether  SEDRIS  should  have  an  XML  interface  in  addition  to 
the  SEDRIS  Transmittal  Format  (STF)  approach.  The  advantage  of  XML  is  broader 
applicability;  the  advantage  of  STF  is  performance.  The  approach  mentioned  above  brings  both 
views  together:  the  identification  of  SEDRIS  functionality  can  be  done  using  an  XML 
description,  while  the  coupling  to  make  use  of  it  can  be  based  on  STF. 


The  general  recommendation  is  to  layer  the  PIM  approach  and  allow  alternative  presentations 
(not  necessarily  UML  based)  as  alternative  and  completing  descriptions.  The  resulting 
framework: 

-  is  hierarchically  organized  in  layers  comparable  with  the  International  Standards  Organization 

(ISO)  Open  Systems  Interconnect  (OSI)  model, 

-  defines  the  interfaces  between  the  layers, 

-  categorizes  alternative  standards  like  the  web  service  stack  is  doing,  and 

-  defines  mappings  between  the  alternative  views  of  a  solution/standard. 


Using  the  four-layer  metamodel  framework  described  in  Table  2,  different  syntax  solutions  can 
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be  used  to  document  the  solution  as  well.  The  framework  allows  one  to  bridge  the  gap  between 
special  and  standardized  solutions  as  described  in  the  second  case  study  as  well  as  bridging  the 
gap  between  various  standards.  It  allows  one  to  integrate  heterogeneous  solutions  under  a 
common  conceptual  management. 

This  framework  must  be  gradually  fdled  with  new  ideas,  such  as  the  Base  Object  Model  (BOM, 
2004)  approach  currently  in  the  SISO  standardization  process.  Results  from  ongoing  research,  in 
particular  (Davis  and  Anderson,  2003)  and  (Weisel,  2004),  among  others,  must  be  used  to 
improve  the  metamodels  through  definition  of  required  metadata  describing  the  services  to  avoid 
effects  as  described  in  (Tolk  and  Muguira,  2003). 

3. 1.1.2  Area  of  Applicability 

Various  exchangeable  and  complementary  standards  exist  on  the  network  level.  On  the 
application  level,  grid  computing  and  other  enabling  standards  are  starting  to  play  a  similar  role. 
The  main  challenge  in  service  oriented  architectures  is  not  only  to  ensure  technical  interchange 
but  also  the  meaningful  composability  of  the  available  services  to  avoid  unintended 
consequences.  One  of  the  requirements  is  the  mapping  of  service  functionality  to  supported 
operational  ideas.  The  conceptual  business  model  of  the  enterprise  to  be  supported  by  the  grid 
must  be  the  guideline  for  the  service  definition.  Implementation  driven  solutions  will  fall  short. 

Modularity,  composability,  interoperability,  reference  data  models,  architecture  frameworks,  and 
many  other  buzzwords  can  be  heard  all  over  M&S  conferences  and  read  in  legions  of  papers. 
Unfortunately,  many  of  these  interoperability  solutions  are  not  too  interoperable  between  each 
other.  The  communities  using  them  are  often  not  even  aware  that  other  communities  are  solving 
the  same  problems,  and  often  solving  them  differently  -  and  eventually  better.  The  result  is  a 
rigid  structure  of  standards  solving  parts  of  the  general  problem  without  creating  the  necessary 
bridges.  A  typical  but  not  unique  example  is  the  lack  of  alignment  of  standards  used  for 
command  and  control  (C2)  and  M&S  support  by  information  technology.  Although  the  user 
requirements  can  be  mapped  to  each  other,  the  standards  started  to  be  aligned  only  recently. 

The  result  is  that  we  are  facing  an  “archipelago  of  standardized  island  solutions”  separated  by 
having  chosen  different  standards  to  address  the  same  problem.  Therefore,  instead  of  having  to 
select  a  solution  that  limits  future  development  within  a  project  by  constraining  the  developers 
and  the  users  too  much,  the  XMSF  Partners  recommend  the  use  of  metamodels  to  enable 
effective  Mapping  and  Migration  Management. 

The  question  for  the  user  is  what  framework  to  choose  and  what  methods  to  apply  to  gain  the 
best  solution  under  applicable  constraints.  It  seems  that  after  having  chosen  one  way,  many 
good  solutions  of  other  methods  applicable  to  solve  a  problem  as  well  cannot  be  applied  any 
longer.  It  is  hard  to  apply  tools  from  one  set  of  standards  to  solve  problems  within  an  alternative 
family,  even  if  in  principal  the  same  conceptual  problem  has  to  be  solved. 

The  problem  is  not  new  in  the  computer  science  world.  The  same  challenges  had  to  be  solved 
when  computer  networks  were  established.  The  early  Ethernet  and  Token-Ring  solutions  were 
hardly  able  to  interconnect,  the  gateway  from  local  area  nets  into  global  networks  required 
highly  qualified  experts.  The  solution  to  this  problem  was  facilitated  by  establishing  a  common 
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model  helping  to  organize  and  map  the  standards  and  proprietary  solutions  of  networking,  the 
ISO/OSI  model.  This  layered  model  helped  to  organize  the  applicability  of  solutions  and 
enabled  to  identify  complementary  as  well  as  alternative  solutions  for  common  problems,  even  if 
these  solutions  look  not  similar  at  all  upon  first  glance. 

Today,  the  domains  needing  standards  are  on  a  higher  level.  Grid  computing  makes  use  of  the 
enhanced  networking  layers,  creating  a  virtual  computer  using  the  interconnected  components 
and  resources.  Enterprise  solutions  targeting  the  IT  supported  seamless  exchange  of  knowledge 
within  the  distributed  centers  of  an  enterprise.  Service  oriented  architectures  (SOA)  are  seen  as 
a  key  enabler  to  support  these  visions.  However,  in  order  to  insure  meaningful  results, 
functionality  must  result  from  meaningful  composition  of  services.  Not  every  composition  that 
is  technically  feasible  makes  sense;  not  everything  that  can  be  connected  can  work  together 
meaningfully.  Recent  works  on  composability  (Tolk  and  Muguira,  2003)  (Weisel,  2004)  (Davis 
and  Anderson,  2003)  are  making  this  obvious,  not  only  in  the  domain  of  M&S.  All  solutions 
currently  proposed  have  their  value  and  should  be  applied  and  evaluated.  In  addition  to  this 
“implementation  driven”  approach  to  solve  the  problem,  conceptual  work  is  necessary  as  well. 
The  key  to  a  common  solution  is  the  use  of  metamodels.  We  recommend  starting  work  on  a 
common  layered  metamodel  to  organize  and  map  the  proposed  standards,  very  similar  to  the 
application  of  the  ISO/OSI  model  for  networking. 

The  use  of  commercially  supported  standards  is  mandatory  for  military  infonnation  technology 
(IT)  in  many  domains.  It  is  therefore  not  only  academically  interesting  but  practical  to  evaluate 
how  the  challenge  of  complementary  and  alternative  standard  mapping  and  alignment  is  dealt 
with  outside  the  Department  of  Defense.  To  this  end,  application  of  the  ISO/OSI  model  so  well 
known  in  the  domain  of  networks  and  similar  efforts  in  the  emerging  domain  of  SOA  are 
discussed.  The  SOA  approach  uses  networks  that  add  a  grid  layer  to  the  network  layer  to  create 
something  like  a  virtual  supercomputer,  which  comprises  all  resources  of  the  underlying 
computers,  builds  the  grid  to  enable  enterprise-wide  computing  based  on  distributed  services 
implemented,  and  executes  distributed  applications  in  this  heterogeneous  IT  environment.  This 
environment  not  only  reflects  the  target  architecture  for  future  parallel  and  distributed 
simulation,  but  also  provides  the  IT  environment  for  future  military  systems  supporting  Joint 
Command  and  Control  (JC2);  i.e.,  the  Global  Information  Grid  (GIG).  These  examples  are 
neither  complete  nor  exclusive.  They  are  meant  to  be  examples  and  are  seen  to  be  an  initial 
frame  for  respective  recommended  SISO  standardization  and  DMSO  policy  activities. 

Using  the  ISO/OSI  Model  to  Align  Families  of  Network  Standards.  The  ISO  has  created  a 
layered  model,  called  the  OSI  model  (Petri,  1998)  describing  defined  layers  in  a  network 
operating  system  starting  with  physical  connections  and  reaching  up  to  the  application  level. 

The  purpose  of  the  layers  is  to  provide  clearly  defined  functions  that  can  improve  network 
connectivity  between  "computer"  manufacturing  companies.  Each  layer  has  a  standard  defined 
input  and  a  standard  defined  output.  There  are  legions  of  papers  out  dealing  with  the  ISO/OSI 
model.  Since  it  was  developed  in  1974  to  standardize  network  communications,  it  was  applied 
successfully  as  a  theoretical  framework.  This  is  the  main  point  stressed  in  this  section  as  well: 
the  ISO/OSI  model  does  not  deliver  the  actual  functions;  this  is  done  by  software  and  hardware 
solutions  that  can  be  mapped  to  this  framework.  In  other  words:  the  ISO/OSI  model  doesn’t 
prescribe  a  solution  but  a  structure  for  a  solution,  which  means,  it  is  a  metamodel.  The  rules  of 
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the  framework  describe,  among  other  topics: 

-  How  network  devices  contact  each  other  &  how  devices  using  different  languages 

communicate; 

-  How  a  network  device  knows  when  to  transmit  or  not  transmit  data; 

-  How  the  physical  network  devices  are  arranged  and  connected; 

-  How  to  ensure  that  network  transmissions  are  received  correctly; 

-  How  network  devices  maintain  a  consistent  rate  of  data  flow; 

-  How  electronic  data  is  represented  on  the  network  media. 

To  this  end,  the  well-known  seven  layers  are  used  to  align  enabling  technical  solutions:  The 
Physical  layer  deals  with  issues  of  the  data  transfer  medium,  such  as  voltage  used.  The  Data  Link 
layer  handles  the  data  transmission  rate  and  the  necessary  specifications.  The  Network  layer 
deals  with  coding,  decoding,  and  checking  of  errors  and  controls  the  flow  of  the  packages.  It  is 
also  the  first  layer  on  which  “logical”  connections  are  established.  The  Transport  layer  ensures 
reliability  of  data,  e.g.,  by  sending  acknowledgements  of  packages.  The  Session  layer  is 
responsible  for  continuity  of  communication  between  nodes  participating  in  a  session.  The 
Presentation  layer  is  the  first  “syntax”  layer,  as  it  checks  the  data  presentation  and  its  correctness 
for  the  last  layer.  Finally,  the  Application  layer  provides  the  network  services  to  the  application. 

The  purpose  of  using  a  framework  as  proposed  in  this  section  is  the  mapping  and  comparison  of 
standards.  Figure  2  shows  examples  of  standards  being  used  alternatively  and  complementarily 
when  implementing  the  ISO/OSI  model  by  different  manufacturers.  As  can  be  seen,  the  standard 
framework  not  only  gives  directions  but  also  allows  comparing  recommendations  and  standards. 
In  summary,  the  framework  and  these  network  standards  have  proven  vital  because  they  ensured 
that  manufacturers  build  equipment  that  intercommunicates  and  interoperates. 
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Figure  2.  Multiple  Implementations  Conforming  to  the  ISO/OSI  Layered  Model 


These  ideas  are  not  limited  to  networks.  In  order  to  cope  with  the  interoperability  challenges 
facing  the  M&S  community,  the  layers  above  the  network  need  to  be  handled  in  the  same  way. 
What  the  ISO/OSI  model  is  doing  for  network  layers  is  needed  on  top  of  this  for  grid  computing, 
service  oriented  architectures,  and  enterprise  wide  solutions  as  well. 


Grid  Computing,  Service  Oriented  Architectures,  and  Enterprise  Solutions.  Traditionally, 
IT  system  development  followed  a  waterfall  model  starting  with  a  set  of  user  requirements, 
which  led  through  several  stages  to  the  system  definition,  system  design,  and  system 
implementation.  The  reality  of  required  distributed  computing  and  the  necessity  for  combining 
information  resources  using  very  heterogeneous  IT  infrastructures  -  different  hardware, 
middleware,  languages,  etc.  -  can  hardly  be  met  by  such  traditional  efforts.  Starting  with  the 
ideas  of  net-centric  operations  and  setting  up  a  system  of  systems,  the  commercial  world,  as  well 
as  the  military  world,  is  moving  from  system  components  delivering  the  operationally  required 
functionality,  towards  service  oriented  architectures.  Within  the  commercial  world,  distributed 
computing  environments  operate  as  a  uniform  service,  which  looks  after  resource  management 
and  security  independently  of  individual  technology  choices.  Grid  computing  is  a  means  of 
network  computing  that  harnesses  the  unused  processing  cycles  of  numerous  computers  to  solve 
intensive  problems  that  are  often  too  large  for  a  single  computer  to  handle.  In  other  words,  grid 
computing  enables  the  virtualization  of  distributed  computing  and  data  resources  such  as 
processing,  network  bandwidth,  and  storage  capacity,  to  create  a  single  system  image  which 
grants  users  and  applications  seamless  access  to  available  IT  capabilities.  Just  as  Internet  users 
view  a  unified  instance  of  content  via  the  Web,  grid  users  see  a  single,  large  virtual  computer.  In 
order  to  access  the  functionality,  services  are  defined  based  on  common  open  standards.  The 
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currently  recommended  way  to  reach  this  goal  is  the  definition  and  implementation  of  SOA. 
Although  it  sounds  like  a  collection  of  randomly  assembled  industry  buzzwords,  the  concept  is 
straightforward:  SOA  is  the  evolutionary  development  of  modular  development  and  pattern 
design  in  the  era  of  grid  computing.  In  other  words:  SOA  is  a  collection  of  composable  services. 
A  service  is  a  software  component  that  is  well  defined,  both  from  the  standpoint  of  software  and 
operational  functionality.  In  addition,  a  service  is  independent,  i.e.,  he  doesn’t  depend  on  the 
context  or  state  of  any  application  that  calls  it. 

Currently,  these  services  are  typically  implemented  as  web  services,  with  rapid  evolution  in 
progress  to  grid  services  -  see  (Morse,  et.  ah,  2004a)  for  further  infonnation.  The  advantage  of 
using  web  standards  in  an  SOA  is  that  the  services  can  more  easily  adapt  to  different 
applications.  Nothing  in  particular  has  to  be  done  programmatically  to  the  service,  except  to 
enable  it  to  receive  requests  and  transfer  results  using  web  based  messaging  and  transportation 
standards.  In  many  cases,  web  services  are  straightforward  and  existing  software  can  easily  be 
adapted  to  create  new  web  services  (White  and  Pullen,  2003)  usable  within  an  SOA. 

From  a  technology  point  of  view,  the  challenge  lies  in  the  architecture  of  the  enterprise  web 
services.  Designing  the  interfaces  and  their  relationships  requires  an  exceptional  knowledge  of 
service  technologies,  the  operational  processes  to  be  supported,  and  the  technology  platfonn 
underlying  the  services  and  the  applications  that  employ  them.  The  architect  must  not  only 
understand  how  web  services  are  technically  constructed,  he  must  plan  their  use  by  both  existing 
and  planned  applications.  If  services  are  not  constructed  to  be  composed  in  a  meaningful  way, 
unintended  effects  within  the  SOA  are  not  only  possible;  they  are  nearly  unavoidable.  The 
examples  given  in  (Tolk  and  Muguira,  2003)  are  just  some  examples  of  such  unintended 
consequences. 

The  same  trend  can  be  observed  in  the  military  world.  Following  the  ideas  of  net-centric  warfare 
(Alberts  and  Hayes,  2002),  future  military  operations  will  be  characterized  by  the  seamless 
sharing  of  information  and  other  resources.  The  technical  backbone  enabling  this  vision  will  be 
the  Global  Infonnation  Grid  (DoD,  2002)  (discussed  further  below).  It  will  establish  a  service- 
oriented  architecture  of  military  services,  from  command  and  control  to  modeling  and 
simulation,  thus  supporting  the  soldiers  in  all  relevant  military  operations. 

As  stated  earlier,  currently  web  services  are  the  favored  option  to  implement  SOA.  As  it  is  the 
case  with  networking  standards,  web  service  standards  are  layered  and  alternatives  are  available 
on  the  various  layers,  resulting  in  the  web  service  stack  shown  below.  Note  that  the  transport 
layer  is  the  connection  to  the  network  standards  defined  previously,  standards  that  focus  on 
communication  and  transport. 

Finally,  the  Enterprise  Architecture  (EA)  defines  the  next  set  of  layers.  Usually,  EA  relate  to  the 
broad  procurement  decisions  by  organizations  regarding  their  organizational  information  support 
systems.  The  concept  of  EA  has  been  defined  and  discussed  variously.  EA  is  defined  by  a 
composition  of  several  architectures  that  have  to  be  aligned  in  order  to  function  correctly. 
(Damton  and  Giacoletto,  1992)  The  components  of  the  EA  are: 
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•  Strategic  Capabilities  Architecture:  captures  the  strategic  vision  as  the  guiding  architecture. 
This  is  the  highest  operational  view  in  which  to  place  “the  pieces  of  the  puzzle”  at  the  right 
place. 

•  Business  Architecture:  devolves  from  this  strategic  capabilities  architecture  by  grouping  core 
competencies  and  necessary  IT  support. 

•  Information  Architecture:  maps  the  overall  information  and  information  exchange  needs  of 
an  organization  based  on  the  strategic  goal.  IT  itself  is  of  a  value  only  if  it  supports  the 
strategy. 

•  Data  Management  Strategy:  follows  from  the  Infonnation  Strategy  and  hence  the  Business 

•  Strategy:  the  organization  makes  decisions  about  how  data  will  serve  its  business  and 
information  needs  as  defined  before.  The  result  is  the  Data  Architecture. 

•  System  Architecture  and  the  Computer  Architecture:  needed  to  organize  the  implementation 
of  the  other  Architectures. 

Within  the  EA,  applications  are  seen  as  data  providers  and  data  users.  Therefore,  SOA  are  the 
logical  next  step  in  this  hierarchy  of  architectures  of  the  EA  (just  as  the  network  standards  can  be 
seen  as  the  foundations  of  SOA). 

Note  the  enterprise  definitions  focus  on  semantics.  There  is  a  conceptual  gap  between  the 
enterprise  definitions  mainly  focusing  on  what  has  to  be  modeled  and  for  what  purpose  on  the 
one  side,  and  the  SOA  and  network  standards  focusing  on  the  technical  levels  of  interoperability 
on  the  other  side.  The  Levels  of  Conceptual  Interoperability  Model  (LCIM)  introduced  in  (Tolk 
and  Muguira,  2003)  deals  with  resulting  challenges  for  conceptual  levels  of  interoperability. 

Some  Applicable  Standards  of  the  Military  Domain.  As  representative  standards  from  the 
military  domain,  we  discuss  the  DoDAF,  C2IEDM,  standards  for  distributed  simulation,  and  the 
GIG: 

•  DoDAF  deals  with  the  architecture  of  military  IT  systems.  It  must  be  applied  to  all 
operationally  used  systems. 

•  C2IEDM  is  a  data  model  standardized  by  NATO,  used  by  the  participating  nations  of  the 
Multilateral  Interoperability  Program  (MIP)  to  exchange  information  describing  the  sphere  of 
military  operations  in  a  manner  operationally,  and  technically  accepted  based  on 
multinational  consensus. 

•  The  actual  standards  for  distributed  simulation  are  Distributed  Interactive  Simulation  (DIS) 
and  High  Level  Architecture  (HLA). 

•  The  GIG  is  the  technical  backbone  to  enable  future  net  centric  operations. 

As  before,  this  section  is  neither  complete  nor  exclusive;  it  just  shows  that  standards  from  the 
various  domains  can  and  should  be  mapped  into  an  according  framework  in  order  to  support  “the 
big  picture.” 

a.  The  Department  of  Defense  Architecture  Framework  (DoDAF).  Architectures  provide  a 
mechanism  for  understanding  and  managing  complexity.  The  purpose  of  the  DoD  Architecture 
Framework  (DoDAF,  2003)  is  to  improve  capabilities  by  enabling  the  quick  synthesis  of  “go-to- 
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war”  requirements  with  sound  investments  leading  to  the  rapid  employment  of  improved 
operational  capabilities,  and  enabling  the  efficient  engineering  of  systems  supporting  the 
warfighter.  The  ability  to  compare,  analyze,  and  integrate  architectures  developed  by  the 
geographical  and  functional,  unified  Commands,  Military  Services,  and  Defense  Agencies  from 
a  cross-organizational  perspective  is  critical  to  achieving  these  objectives. 

In  DoDAF,  the  three  major  views  logically  combine  to  specify  an  architecture.  The  described 
system  is  not  limited  to  information  technology.  DoDAF  has  been  designed  to  describe  military 
systems,  such  as  architectures  that  enable  capabilities  such  as  theatre  ballistic  missile  defense. 
The  necessary  three  views  are  the  Operational  View  (OV),  Systems  View  (SV),  and  Technical 
Standards  View  (TV): 

•  The  Operational  View  is  a  description  of  the  tasks  and  activities,  operational  elements,  and 
information  flows  required  to  accomplish  or  support  a  military  operation. 

•  The  Systems  View  is  a  description,  including  graphics,  of  systems  and  interconnections 
providing  for,  or  supporting,  warfighting  functions.  These  views  potentially  will  close  the 
conceptual  gap  between  what  has  to  be  modeled  and  why  (operational  view)  and  how  this  is 
done  (technical  view). 

•  The  Technical  View  is  the  minimal  set  of  rules  governing  the  arrangement,  interaction,  and 
interdependence  of  system  parts  or  elements,  whose  purpose  is  to  ensure  that  a  confonnant 
system  satisfies  a  specified  set  of  requirements. 


In  summary,  the  operational  view  is  the  view  of  the  warfighter,  the  systems  view  is  the  view  of 
the  system  designer  or  technical  supporter,  and  the  technical  view  is  the  set  of  necessary 
standards  and  alternative  technical  solutions  enabling  the  composition  of  components  of  the 
system  level  to  deliver  the  functionality  needed  on  the  operational  level. 

DoDAF  is  a  tool  to  structure  the  Enterprise  Architecture  in  the  military  domain.  Every  one  of  the 
DoDAF  products  will  be  implemented  using  a  couple  of  additional  standards  on  lower  levels 
within  the  military  EA.  The  operational  views  are  used  to  model  the  strategic  visions,  the 
business  architecture.  The  system  views  close  the  gap  between  the  concepts  and  the  IT 
infrastructure  described  by  the  system-  and  computer  architecture.  How  DoDAF  can  play  a 
valuable  role  to  enable  M&S  support  for  capability  based  planning  was  only  recently  presented 
(Atkinson,  2004). 

It  is  furthermore  of  interest  that  there  are  several  approaches  in  progress  to  migrate  DoDAF 
products  to  more  industry  supported  ideas,  in  particular  using  UML  diagrams  to  describe  the 
products.  The  trend  to  extend  UML  to  better  describe  systems  has  to  be  taken  into  account  as 
well  as  the  System  Modeling  Language  (SysML)  that  is  gaining  visibility  regarding  EA 
modeling  concepts  and  within  the  US  government  with  respect  to  use  in  DoDAF. 

It  is  worth  mentioning  that  in  order  to  support  the  dissemination  of  DoDAF  products  and  feed 
several  supporting  tools,  the  way  to  store  the  infonnation  describing  the  products  of  the  views 
was  standardized  by  introducing  the  Core  Architecture  Data  Model  (CADM).  The  products  of 
DoDAF  describing  the  views  are  typically  graphics  and  text  first.  The  CADM  helps  to  store  an 
architecture  description  in  a  way  that  is  interchangeable  between  users  and  tools.  CADM 
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comprises  data  elements  to  describe  a  system  and  the  architectural  views  as  specified  within  the 
DoDAF.  It  is  therefore  a  tool  useful  for  the  infonnation  architecture.  However,  CADM 
specifies  that  data  have  to  be  exchanged  between  components  and  which  standards  have  to  be 
used,  but  it  is  not  a  data  model  to  exchange  data  in  the  operational  level  (which  is  part  of  the 
system  or  computer  architecture  -  or  even  lower).  This  is  done  by  operational/tactical  data 
models  as  used  by  tactical  systems. 

In  summary,  the  enterprise  aspects  of  strategic  goals  and  business  models  to  be  supported  are 
reflected  in  the  operational  views  of  DoDAF,  Infonnation  and  Data  Architecture  are  the  base  for 
the  system  views,  and  the  applied  standards  have  to  be  captured  in  technical  views.  DoDAF  and 
the  use  of  commercially  supported  enterprise  architecture  description  methods  are  no  longer 
mutually  exclusive,  but  the  trend  is  towards  the  approaches  being  merged  and  mutually 
supportive. 

b.  Command  and  Control  Information  Exchange  Data  Model  (C2IEDM).  As  many 
interoperability  challenges  cope  with  the  coupling  of  legacy  systems  via  predefined  interfaces, 
one  area  of  particular  interest  is  standardized  data  exchange  between  such  components.  Due  to 
various  reasons  ranging  from  intellectual  property  protection  to  the  use  of  undocumented  legacy 
code,  components  are  often  treated  as  black  boxes.  Furthermore,  static  systems  focusing  on  data 
storage  and  representation  have  no  need  for  behavioral  descriptions,  as  there  is  no  behavior 
modeled  within  them.  A  main  portion  to  gain  a  high  level  of  interoperability  between  such 
systems  is  contributed  by  standardized  data  elements  used  for  information  exchange  between 
such  systems,  often  referred  to  as  a  common  language  or  a  common  ontology.  The  limits  of  this 
approach  have  been  shown  in  (Tolk  and  Muguira,  2003)  and  will  not  be  repeated  here. 

The  real  potential  of  SOA  lies  in  the  possibility  to  compose  services  and  to  orchestrate  their 
execution  enabling  new  functionality  compositions  to  fulfill  the  current  often  changing  user 
requests  “on  the  fly.”  Many  users  perceived  the  resulting  challenge  of  interoperable  data 
exchange  between  such  services  to  be  solved  by  using  XML.  However,  although  the  application 
of  the  XML  enabled  a  new  level  of  interoperability  for  heterogeneous  IT  systems,  it  doesn’t 
ensure  that  data  exchanged  is  interpreted  correctly  by  the  receiving  system.  This  motivates  data 
management  to  support  unambiguous  definition  of  data  elements  for  information  exchange. 
Using  a  common  reference  model  improves  this  process  leading  to  "model  based  data 
management  (MBDM)"  as  introduced  to  SISO  in  (Tolk,  2004b)  and  technically  detailed  in 
(Tolk,  2004c).  The  main  idea  is  to  use  a  common  reference  data  model  to  unambiguously  define 
the  data  to  be  exchanged;  namely,  C2IEDM. 

C2IEDM  is  the  data  model  used  within  the  Multilateral  Interoperability  Program  (MIP)  for  data 
exchange  between  operational  systems  as  well  as  for  data  management  of  information  exchange 
requirements  between  national  C2  systems.  Model  documentation  is  available  on  the  program 
website  (MIP,  2004)  and  comprises  definitions  for  all  data  elements  of  C2IEDM,  all  relations,  as 
well  as  explanations  and  background  infonnation.  Besides  the  technical  maturity  of  this  data 
model,  the  choice  of  C2IEDM  as  the  core  model  for  military  MBDM  was  driven  by  the  fact  that 
all  participating  MIP  nations  agreed  that  the  infonnation  exchange  captured  in  C2IEDM  is 
operationally  relevant  and  sufficient  for  allied  operations.  In  other  words:  military  and  technical 
experts  from  10  full  member  nations  (Canada,  Denmark,  France,  Germany,  Italy,  The 
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Netherlands,  Norway,  Spain,  United  Kingdom,  and  United  States)  as  well  as  14  associate 
member  nations  agreed  that  C2IEDM  is  an  adequate  and  operational  meaningful  way  to 
exchange  information  about  military  operations,  including  new  tasks  like  anti-terror  operations. 
C2IEDM  covers  176  information  categories  including  over  1,500  individual  content  elements 
(MIP  Block  I,  see  (MIP,  2004)  for  details). 

Technically,  C2IEDM  utilizes  the  concepts  of  categories  and  subcategories  to  model  existing 
information  exchange  requests,  such  as  orders  and  reports,  in  military  operations  and  a  set  of 
rules  allowing  for  extension  of  the  model  without  having  to  modify  the  existing  kernel. 
Furthermore,  C2IEDM  distinguishes  between  the  generic  hub,  which  is  internationally 
standardized  by  NATO  in  form  of  an  Allied  Data  Publication  and  the  sub-functional  areas 
comprising  additions  and  refinements  being  of  national  concern.  Although  the  focus  of 
C2IEDM  is  information  exchange,  some  national  command  and  control  systems  (among  others 
Canada,  Italy,  and  The  Netherlands)  not  only  use  the  C2IEDM  as  an  interface  but  use  it  as  a 
tactical  data  model  as  well.  Finally,  it  is  worth  mentioning  that  several  organizations  are 
working  on  XML  versions  of  the  C2IEDM. 

In  summary,  the  concept  of  SOA  requires  a  common  understanding  of  the  data  to  be  exchanged 
between  the  services.  If  the  services  are  using  different  data  models  internally,  a  mapping 
between  the  data  models  is  necessary.  In  trivial  cases,  some  of  this  mapping  can  be  done 
automatically,  e.g.,  mapping  the  data  elements  “First  Name”  and  “Last  Name”  of  one  model  to 
the  data  element  “Customer  Name”  in  another  model.  A  good  overview  of  applicable  methods 
for  automatic  mapping  of  XML  data  is  given  in  (Su,  et.  ah,  2001). 

However,  the  author  is  convinced  that  to  cope  with  the  challenge  in  general,  data  engineering  as 
defined  in  (Tolk,  2004b)  is  needed.  It  is  not  so  important  which  data  model  is  used  for  MBDM, 
it  is  more  important  that  an  unambiguously  defined  data  model  is  used  as  a  reference.  The 
methods  of  federated  database  development  as  introduced  in  (Sheth  and  Larson,  1990)  or  XML 
derivates  of  it  can  always  be  used  to  map  this  data  model  onto  each  other,  if  they  cover  the  same 
information  space. 

Note  that  tactical  data  models,  such  as  the  C2IEDM  or  the  Joint  Common  Database  (JCDB)  or 
the  database  of  the  Future  Combat  Systems  (FCS),  have  to  capture  and  structure  the  information 
that  has  to  be  exchanged  on  the  battlefield  with  other  participating  systems.  This  is  a  completely 
different  purpose  and  hence  a  different  level  in  the  enterprise  architecture  hierarchy  than  the 
CADM  described  previously.  The  role  of  the  CADM  is  to  enable  the  exchange  of  information 
about  the  architecture  of  the  systems,  not  operational  data.  In  this  sense,  the  tactical  data  models 
such  as  C2IEDM  are  “just  a  technical  view”  in  the  CADM;  in  other  words,  CADM  and  C2IEDM 
are  both  applicable  at  the  same  time  on  different  levels  of  the  enterprise  architecture  to  be 
supported. 

c.  Standards  for  Distributed  Simulation.  In  one  sense,  M&S  is  an  IT  service  to  support  the 
warfighter.  When  M&S  services  have  to  reach  the  warfighter  using  operational  systems,  the 
standards  discussed  in  this  document  have  to  be  applied.  If  M&S  services  are  used  in  the 
operational  context,  they  have  to  follow  the  same  rules  and  constraints  as  other  Joint  Command 
and  Control  services.  The  same  ideas  of  interchangeable  alternative  implementations  in  various 
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layers  with  well-defined  interfaces  embedded  in  a  common  conceptual  (business)  model  are 
applicable  for  M&S  solutions;  therefore,  they  must  be  of  interest  to  the  SISO  community  as  a 
whole,  even  without  having  their  operational  use  in  mind. 

Currently,  the  two  dominant  standards  for  military  distributed  simulation  systems  are  the 
Distributed  Interactive  Simulation  (DIS,  1995)  protocol  and  the  High  Level  Architecture  (HLA, 
2000).  (Atkinson,  2004)  showed  not  only  that  M&S  needs  to  support  the  DoDAF,  but  also 
provided  examples  and  references  on  how  the  DoDAF  can  be  used  to  support  M&S.  Another 
example  of  the  connectivity  of  DoDAF  products  and  M&S  applications  is  given  in  (Wittman,  et. 
ah,  2003),  where  the  DoDAF  products  are  used  to  capture  the  operational  view  to  be  supported 
by  the  M&S  functionality.  This  shows  how  M&S  is  embedded  into  the  military  EA  on  all  levels. 
Furthennore,  (White  and  Pullen,  2003)  showed  how  M&S  components  can  be  migrated  towards 
web-based  solutions.  Their  results  are  generalized  in  this  section  dealing  with  the  migration  of 
M&S  solutions  based  on  the  HLA  or  the  DIS  standard  to  become  applicable  as  M&S  services  in 
SO  A  environments. 

Both  standards,  DIS  and  HLA,  treat  simulation  systems  as  black  boxes.  This  is  especially  the 
case  for  DIS,  which  generates  Protocol  Data  Units  (PDU)  as  a  data  source  and  consumes  them  as 
a  data  sink.  There  is,  however,  no  interface  mechanism  to  orchestrate  the  system  and  there  is  no 
way  to  describe  the  behavior.  An  M&S  component  being  DIS  enabled  is  therefore  easy  to 
integrate  into  a  SOA:  the  only  thing  to  do  is  to  change  the  PDU  interface  to  an  XML  interface 
(XML  descriptions  for  PDU  are  easy  to  program)  and  the  DIS  interface  with  a  web  service 
interface  (which  can  be  done  automatically).  It  may  even  be  easier  to  simply  wrap  the 
component  and  translate  the  protocols  within  the  wrapping  layer. 

In  principle,  the  same  is  true  for  HLA;  however,  the  interface  is  more  complicated  due  to  the 
specification  of  the  Runtime  Infrastructure  (RTI).  However,  that  this  functionality  can  be 
mapped  to  other  middleware  solutions,  such  as  using  Common  Object  Request  Broker 
Architecture  (CORBA)  specifications  to  emulate  the  RTI  functionality,  has  already  been  shown 
several  times.  The  general  mapping  can  be  done  using  MDA.  This  is  already  commercially 
supported  by  new  solutions,  such  as  by  the  Integrated  Development  Environment  (IDE) 
SIMplicity  (Parr  and  Keith-Magee,  2003):  At  the  user  interface  level,  SIMplicity  presents  the 
developer  with  a  modeling  environment  to  specify  the  Platform  Independent  and  Platform 
Specific  models  for  their  simulation,  applying  UML  notation  wherever  applicable.  The 
modeling  process  supports  the  developer  through  the  design,  implementation,  and  execution 
phases  of  the  simulation  development  life  cycle.  From  the  model,  a  code  generation  engine  is 
employed  to  automatically  create  all  the  integration  and  component  stub-code  required  to 
support  the  simulation  design  on  the  targeted  Platform  Specific  middleware.  M&S  components 
can  be  derived  for  various  platfonns  and  middleware  solutions,  such  as  the  various  RTI 
derivatives  1.3  NG  or  IEEE  1516,  or  the  generation  of  a  necessary  DIS  protocol  access  layer. 

In  summary,  the  current  M&S  standards  can  not  only  be  mapped  to  each  other,  but  methods  as 
described  in  (White  and  Pullen,  2003)  and  (Parr  and  Keith-Magee,  20003)  can  help  to  make 
them  available  in  the  form  of  operationally  applicable  M&S  web  services  within  an  enterprise 
architecture. 
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d.  Global  Information  Grid  (GIG).  Following  the  ideas  of  net-centric  warfare  (Alberts  and 
Hayes,  2002),  future  military  operations  will  be  characterized  by  the  seamless  sharing  of 
information  and  other  resources.  The  technical  backbone  enabling  this  vision  will  be  the  Global 
Information  Grid  (DoD,  2002),  which  will  be  implemented  using  the  Internet  Protocol  version  6 
as  the  technical  baseline.  It  will  establish  a  SOA  of  military  services,  from  command  and  control 
to  modeling  and  simulation,  supporting  the  soldiers  in  all  relevant  military  operations.  The  GIG 
will  merge  the  ideas  such  as  described  in  this  section  and  will  make  them  applicable  to  support 
the  warfighter  in  all  his  tasks. 

Even  more  challenging  than  the  technical  aspects  of  GIG  will  be  the  organizational  ones.  As  the 
GIG  will  be  a  common  information  exchange  hub,  the  IT  backbone  for  military  IT  support,  the 
business  cases  of  the  DoD  have  to  change  from  pipe  to  hub  structures.  Infonnation  should  and 
will  be  made  available  to  every  user  in  need  on  his  request  and  not  by  decision  of  the  data 
producer.  The  ideas  are  described  in  (Alberts  and  Hayes,  2002). 

The  organizing  principle  is  the  establishment  of  communities  of  interest  (COI).  While  the 
Defense  Information  Systems  Agency  (DISA)  will  deliver  a  set  of  enterprise  wide  applicable 
core  services  in  the  form  of  the  Net  Centric  Enterprise  Services  (NCES)  or  GIG  Enterprise 
Services  (GES),  the  user  communities  will  be  responsible  for  their  own  namespace  and  process 
management.  The  methods  described  in  this  document  will  help  avoiding  unintended  behavior 
within  this  military  SOA  when  composing  services,  in  particular  when  more  than  one  COI  are 
involved. 

Some  salient  points  regarding  an  M&S  COI  for  the  GIG: 

•  The  M&S  COI  for  the  GIG  is  now  in  the  process  of  formation 
o  High-level  DMSO-DISA  agreement 

o  Namespace  is  critical  to  effective  XMSF  deployment 

•  Opportunity  to  create  effective  C4I-Simulation  links  in  Horizontal  Fusion  (HF) 
o  ASD(NII)  program  to  demonstrate  breaking  down  stovepipes 

o  Annual  “graduation  exercise”  in  August  displays  C4I  best-of-breed  Web  services 

•  Opportunity  to  show  effectiveness  of  M&S  Web  services 
o  XMSF  HF  goals: 

■  August  04:  provide  context  for  HF  using  simulation  such  as  JFCOM’s  Joint  Urban 
Operations  with  an  early  XC2I  prototype 

■  August  05:  operate  XBML  and  XC2I  using  real  C4I  system  feeds 
o  Effects  long  term  community  objective 

•  Integrated  C4I  environment  with  simulation  tools  supporting  military  operations 

e.  Military  Mission  and  Means  Framework.  Another  topic  is  the  Military  Mission  and  Means 
framework  (MMF)  (Sheehan,  et.  ah,  2003),  which  may  complement  DoDAF  products  in  a  way 
directly  applicable  to  the  M&S  domain.  Analyses  of  the  MMF  by  the  Joint  Staff  as  well  as 
DoDAF  developers  showed  that  DoDAF  and  MMF  are  not  only  overlapping  views  to  be 
supported  by  underlying  implementation  levels,  including  simulation  and  Command  and  Control 
operations,  but  can  be  used  to  mutually  support  each  other.  It  can  be  said  that  the  operational 
view  of  DoDAF  is  dealing  with  the  missions  and  the  systems  view  with  the  means  (using  the 
standards  defined  in  the  technical  view  to  exchange  information).  The  domain  of  executable 
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architectures,  as  currently  discussed  for  the  Joint  National  Training  Capability  (JNTC),  is  also 
affected  by  the  proposed  standards.  Only  recently,  ODU/VMASC  participated  in  a  workshop  of 
experts  in  executable  architectures  sponsored  jointly  by  Assistant  Sec  of  Defense  for  Nil  and 
Deputy  Dir,  Technology,  DMSO.  The  established  working  group  will  develop  a  coordinated 
approach  for  addressing  the  technical  obstacles  to  executing  architectures,  establish  coordination 
process  for  technology  development  across  Services  and  OSD,  and  contribute  to  the  revision  of 
DoDAF.  Based  on  Army  Training  Support  Center  (ATSC)/VMASC  Training  Support  System 
(TSS)  modeling  and  Enterprise  Architecture  Framework  initiatives,  Co-Chairs  were  very 
interested  in  exploring  how  the  TSS  could  fit  into  future  DoD  executable  architecture 
development,  especially  the  integration  of  training  support  enterprise  modeling  with  emerging 
DoDAF  architecture  modeling  and  simulation  tools.  A  program  plan  for  the  working  group  is 
being  developed  with  potential  of  identifying  the  TSS  as  a  pilot  executable  architecture  testbed 
for  the  DoD  initiative.  Discussions  continue  between  VMASC  and  ATSC  to  explore  the 
proposal  and  potential  impact  (TRADOC,  2004).  First  results  concerning  an  executable  DoDAF 
are  given  in  (Dryer  and  Berbesi,  2004).  One  impact  is  that  the  CADM  must  comprise  the  data 
elements  needed  for  an  executable  architecture.  Note  that  this  may  include  in  special  studies  the 
use  of  C2IEDM  to  exchange  information  between  systems  when  simulating  the  systems  view. 

3. 1.1.3  Maturity 

Many  of  the  standards  and  practices  are  well  established  at  this  point,  although  the  development 
community  continues  to  rapidly  evolve.  A  clear  road  map  is  needed  to  help  the  community 
through  the  vast  array  of  standards  and  technology  initiatives  and  to  set  a  foundation  for  future 
interoperability  and  reuse. 

3.1. 1.4  Required  Changes 

In  the  previous  sections,  an  exemplary  selection  of  standards  dealing  with  the  broad  aspect  of 
interoperability  for  components  of  the  IT  support  for  warfighters  has  been  given.  However, 
already  this  small  selection  showed  the  variety  of  alternative  solutions,  some  of  them  exclusive, 
others  complementary  or  real  alternatives.  In  other  words:  choosing  the  right  family  of  standards 
early  is  currently  crucial  for  interoperability  success.  As  discussed,  technical  standards  alone  are 
not  sufficient  to  reach  meaningful  interoperable  solutions.  The  technical  solutions  must  be 
embedded  into  common  concepts  applicable  to  all  components  of  the  enterprise  architecture. 
Strategic  objectives  and  the  business  rules  must  be  aligned  and  hannonized.  To  this  end,  the 
commercial  world  through  new  approaches  such  as  grid  computing  and  service  oriented 
architectures  and  the  military  world  through  its  growing  attention  to  the  GIG  and  GES  need 
metamodels  to  manage  the  alternative  solutions.  Metamodeling  is  precisely  defining  constructs 
and  rules  needed  for  creating  semantic  models.  It  enables  transparency  of  the  model  and  its 
assumptions  and  constraints  necessary  for  composable  services  without  forcing  open-source 
solutions,  hence  protecting  intellectual  property.  Mapping  transforms  two  models  in  an 
unambiguous  way  into  each  other  through  defined  mediation  rules.  Although  no  general 
solution  has  emerged  so  far,  the  use  of  ETML  for  modeling  on  all  levels  is  becoming  a  de  facto 
standard.  Such  metamodels  can  be  used  to  map  and  merge  existing  standard  solutions  of  the 
commercial  and  the  military  domain,  including  networking  standards,  web  service,  SOA, 
DoDAF,  NCES  and  GES.  SISO  can  and  should  play  a  role  in  setting  up  this  framework  to 
actively  push  M&S  standardization  efforts  into  related  domain  and  respectively  use  their 
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solutions  to  support  SISO  efforts.  XMSF  partners  are  working  directly  with  and  through  SISO 
to  rapidly  introduce  metamodeling  concepts  and  techniques  to  the  M&S  community. 

3.1. 1.5  Timetable  for  Adoption  of  Changes 

There  are  numerous  initiatives  already  in  progress  across  DoD  indicating  that  the  concepts, 
though  not  broadly  understood,  are  already  being  accepted  and  actively  promoted.  Policy 
changes  to  help  guide  the  community  are  needed  in  the  near  term  (2005-2006). 

3.1.2  Extensible  3D  Graphics 

3. 1.2.1  Description 

X3D  is  a  powerful  and  extensible  open  file  fonnat  standard  for  3D  visual  effects,  behavioral 
modelling  and  interaction.  It  provides  an  XML-encoded  scene  graph  and  a  language-neutral 
Scene  Authoring  Interface  (SAI).  The  XML  encoding  enables  3D  to  be  incorporated  into  web 
services  architectures  and  distributed  environments,  and  facilitates  moving  3D  data  across 
applications.  The  SAI  allows  real  time  3D  content  and  controls  to  be  easily  integrated  into  a 
broad  range  of  web  and  non- web  applications. 

3. 1.2.2  Area  of  Applicability 

X3D  replaces  the  hodgepodge  of  incompatible  products  with  an  interchange  format  that  can 
translate  products  into  shared  scenes  for  web  interoperability. 

3. 1.2.3  Maturity 

The  primary  X3D  specification  has  been  approved  by  ISO  as  an  International  Standard. 
Supporting  X3D  specifications  for  XML,  Classic  VRML,  Compressed  Binary  encodings  and  for 
ECMAScript/Java  language  bindings  are  now  in  final  review,  with  approval  likely  in  April  2005. 
X3D  has  been  approved  for  Navy-wide  use  by  the  Department  of  the  Navy  Chief  Information 
Officer  (DON  CIO)  Business  Standards  Council.  An  open  source  reference  implementation  is 
available  for  use  and  numerous  companies  have  released  products  conformant  to  the  X3D 
specification,  with  others  in  development. 

3.1.2.4  Required  Changes 

DMSO  failure  over  the  2002-2004  timeframe  to  provide  open-source  licensing  tenns  for 
SEDRIS  software  means  that  Web3D  developers  are  pursuing  alternate  codebases  to  achieve 
similar/identical  functionality.  SEDRIS  has  been  unresponsive  to  multiple  requests  to  pursue 
XML  bindings  to  enable  web  services  compatibility  and  interoperability. 

A  just-completed  X3D  Technical  Summit  members-only  event  listed  about  three  dozen  technical 
imperatives  for  2005. 

Just  as  the  Navy  has  taken  the  step  to  approve  X3D  as  a  unifying  approach  for  visualization,  the 
same  decision  needs  to  be  made  by  DMSO  for  the  DoD  M&S  community. 
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3. 1.2.5  Timetable  for  Adoption  of  Changes 

The  X3D  standard  is  in  an  annual  ISO-standard  update  cycle.  The  Web3D  Consortium  is 
currently  accepting  comments  on  Amendment  1  to  the  X3D  abstract  specification,  ISO/IEC 
19775,  including:  Computer-Aided  Design  (CAD)  Geometry  component;  CAD  Interchange 
profile;  Programmable  Shaders  component;  3D  Texturing  component;  and  Cubic  Environment 
Texturing  component.  Promulgation  of  X3D  as  a  standard  for  DoD  M&S  use  can  begin  now. 

3.1.3  Web  Services 

3. 1.3.1  Description 

A  Web  services  is  “a  software  system  designed  to  support  interoperable  machine-to-machine 
interaction  over  a  network.  It  has  an  interface  described  in  a  machine-processable  format 
(specifically  WSDL).  Other  systems  interact  with  the  Web  service  in  a  manner  prescribed  by  its 
description  using  SOAP  messages,  typically  conveyed  using  HTTP  with  an  XML  serialization  in 
conjunction  with  other  Web-related  standards.”  (W3C,  2004a)  Web  services  are  being  supported 
and  adopted  by  industry  as  a  way  to  securely  integrate  heterogeneous  applications  over  the 
Internet  (Ferguson,  et.  ah,  2004).  As  such,  it  is  a  primary  strategy  in  XMSF  as  described  in 
(Brutzman,  et.  ah,  2002)  (Brutzman  and  Tolk,  2003)  (Pullen,  et.  ah,  2004).  From  (Barry,  2003): 

[Web  services  and  service-oriented  architectures]  ...are  going  to  fundamentally  change  the 
way  we  build  our  internal  systems  -  the  infonnation  systems  that  support  our  organizations  - 
and  how  our  internal  systems  interact  with  external  systems...  We  are  on  the  cusp  of  building 
“plug-compatible”  software  components  that  will  reduce  the  costs  of  our  software  systems  at 
the  same  time  increasing  the  capabilities  of  the  systems.  A  service-oriented  architecture  is 
essentially  a  collection  of  services.  Connections  among  services  are  Web  services.  A 
service  is  a  function  that  is  well-defined,  self-contained  and  does  not  depend  on  the  context  or 
state  of  other  services. 

A  Web  services  stack  was  shown  in  Figure  1  earlier.  Fundamentally,  the  stack  consists  of: 

•  Transport ;  e.g.,  communications  protocols  such  as  HTTP,  SMTP,  FTP,  etc. 

•  Messaging;  e.g.,  using  SOAP  (W3C,  2003) 

•  Description;  e.g.,  using  WSDL  (W3C,  2001) 

•  Quality  of  Experience; 

•  Service  Composition;  e.g.,  various  processes  for  discovery,  such  as  UDDI  (OASIS,  2004),  for 
aggregation  through  Business  Process  Execution  Language  for  Web  Services  (BPEL4WS)  (IBM 
2003),  and  for  choreography  (W3C,  2004b). 

As  discussed  earlier,  these  are  building  blocks  for  the  GIG  SOA.  Application  of  such  techniques 
clearly  apply  to  a  characterization  of  XMSF  applications,  while  applying  much  more  broadly  as 
well. 

3. 1.3.2  Area  of  Applicability 

The  fundamental  area  of  applicability  is  the  GIG.  The  formation  of  the  M&S  COI  within  the 
GIG  indicates  recognition  that  future  warfighting  systems,  including  M&S  systems,  will  be 
composed  from  services  enabled  by  the  emerging  and  evolving  standards.  Through  2004,  many 
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XMSF  technical  efforts,  multiple  projects,  and  capstone  demonstrations  at  I/ITSEC  provided 
examples  and  initial  capabilities  to  help  inform  the  M&S  community  in  the  application  of  these 
technologies  across  a  broad  front  -  refer  to  Section  5  of  this  document  for  more  detail  on  the 
Experimentation  Command  and  Control  Interface  (XC2I)  exemplar. 

The  intention  is  to  develop  and  text  such  exemplars  in  operational  environments,  laboratory 
environments,  or  under  the  auspices  of  standards  organizations  such  as  Web3D  before 
submitting  proposals  to  relevant  standards  bodies.  Some  specific  areas  of  exploration  are  DIS- 
XML  (working  group  launched  in  Web3D  in  January  2005)  targeted  to  SISO  and  IEEE,  XOM 
targeted  for  IETF,  and  XML  Schema-based  Binary  Compression  (XSBC)  for  the  W3C  Binary 
Characterization  Working  Group. 

NPS  held  a  restart  meeting  for  the  Web3D  Consortium  DIS  working  group,  on  11-12  January 
2005  in  Monterey,  with  teleconference  access  provided.  All  participants  are  enthusiastic  about 
establishing  this  working  group  and  getting  some  powerful  work  done  together.  Meeting 
minutes  are  provided  below  to  illustrate  the  activities  expected  to  occur  along  various  fronts. 

Meeting  participants:  Alan  Hudson,  Yumetech;  David  Maynard,  L3;  Don  McGregor,  NPS;  Mark 
Pullen,  GMU;  Don  Brutzman,  NPS 

Strategic  objective  for  DIS-XML  working  group:  How  can  X3D  and  DIS  open  up  the  modeling 
&  simulation  (M&S)  market  to  open-standards  Web-based  technologies. 

Goals: 

•  Explore  &  demonstrate  viability  of  DIS,  DIS-XML  networking  support  for  X3D 
o  Workability,  interoperability  of  IEEE  DIS  protocol  with  other  web  systems 
o  Suitability  and  usage  for  Web  Services 

o  Wide-area  networking  using  XMSF  Cross-network  Overlay  Multicast  (XOM) 
o  Streamability  of  XML-based  behavior  information  for  X3D 

•  Continued  development  of  DIS-related  open-source  codebases 
o  DIS-XML  schema 

o  DIS-XML  autogenerated  Java  codebase 
o  DIS-Java-VRML  maintenance 

o  XOM  codebase,  testing  and  establishing  multicast  simulation  channels 
o  Utilities:  packet  recording/playback,  compressed  archiving 

o  Compression  comparisons  using  XML  Schema-based  Binary  Compression  (XSBC) 

•  Addition  of  DIS-specific  node(s)  to  X3D 

o  Maintenance  and  extension  of  the  DIS  component  for  X3D  Specification 
o  DISEntityManager,  DISEntityTypeMapping  for  new-entity  discovery/display 
o  Suitability  of  other  existing  DIS  Protocol  Data  Units  (PDUs)  to  X3D 
o  Best  practices  for  applying  DIS  to  X3D  Geospatial  scenes 

•  Standardization  collaborations 

o  Web3D:  X3D  Specification  amendments 
o  SISO:  IEEE  DIS  Specification 
o  IETF:  overlay  multicast  standardization 
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Who  is  interested,  and  why: 

•  George  Mason  University  (GMU):  XMSF,  XOM 

•  Link  team  of  L3  Communications:  DIS,  DIS-XML,  XOM,  X3D 

•  Old  Dominion  University  (ODU):  DIS,  X3D 

•  Media  Machines:  X3D  DIS  component  implemented  in  C++ 

•  Naval  Undersea  Warfare  Center  (NUWC):  participate  in  wide-area  simulations 

.  NPS  MOVES  Institute:  XMSF,  X3D,  XSBC,  DIS,  DIS-XML,  XOM,  wide-area  sims 

•  Planet9:  X3D,  wide-area  simulations 

.  Yumetech:  Xj3D  browser,  XMSF,  X3D,  XSBC 


Working  group  charter  refresh: 

•  Group  mechanics: 

o  email  lists:  dis-xml@web3D.org  (members)  and  xmsf-announce@MovesInstitute.org 
o  website:  http://www.web3d.org/_tbd_  (both  public  and  member-only) 
o  cvs  site:  http://sourceforge.net/projects/xmsf 
o  XMSF  bugtracker:  DIS-XML  component  available 
http://xchat.movesinstitute.org/bugzilla 
o  meet  every  other  week  via  teleconference 

o  use  GMU’s  NEW  multimedia  conferencing  to  test  networking,  audio/video 
http://netlab.gmu.edu/NEW 

•  Access 

o  Web3D  members  only,  under  new  membership  agreement 

o  All  submissions  under  Intellectual  Property  Rights  (IPR)  and  predeclared  available  for 
standardization  as  Royalty  Free  (RF)  use 

o  Meeting  plans:  Web3D  Symposium,  SIGGRAPH,  XMSF  deep  dives,  SIW,  etc. 
o  L3  may  be  able  to  host  a  f2f  meeting  (Orlando  FL  or  Arlington  TX) 

NPS  presentations: 

•  status  of  existing  dis-java-vrml  and  dis-java  codebases 

•  recent  progress  establishing  dis-xml  codebase,  which  includes  DIS  packets  mapped  to/from 
XML 

•  how  to  retrieve  codebases  from  SourceForge  via  CVS 

•  use  of  DIS  in  Rick  Goldberg's  DISKIT  package  in  the 

•  Simkit/Viskit  Discrete  Event  Simulation  (DES)  application 
http://www.1novesinstitute.0rg/xmsf/xmsf.html#Projects-WCM 

Yumetech  presentations: 

•  DIS  component  support  in  Xj3D 

•  proposed  new  nodes:  DISEntityManager  and  DISEntityTypeMapping  will  discover  new  entities 
from  network  traffic  and  display  corresponding  entity  geometry  from  announced  X3D  url(s) 

•  Picking  sensors  for  object-to-object  collision  detection  inside  X3D,  line-of-sight  (LOS) 
detection,  virtual  sensors,  terrain  following,  etc. 

L3  Link  presentation: 

•  recent  I/ITSEC  demonstrations:  will  distribute  slideset  once  DIS-XML  mailing  list  established 
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•  lessons  learned  and  recommendations  using  dis-java  and  alpha  dis-xml  code 

•  considering  what  areas  to  work  on 

Work  list,  near  term: 

•  Revised  charter:  Don  Brutzman 

•  Website  revamp:  Don  Brutzman 

•  DIS-XML  release:  Don  McGregor 

•  XOM  release:  Mark  Pullen  &  Denny  Moen  GMU,  Don  McGregor 

•  Sourceforge  fixups:  Don  McGregor 

•  Mimi  Nguyen  ODU  provided  DIS-Java  classes  for  PduSniffer  and  DIS  electronic  emissions 
PDUs,  need  to  be  integrated  in  codebases 

DIS-Java  build:  Alan  Hudson 

DIS-XML  build:  Don  McGregor 

•  Demonstrate  DIS  X3D  viability  with  GeoSpatial  profile  scenes 

Xj3D,  DIS-Java:  Alan  Hudson,  Don  McGregor  (maybe  in  AUV  Workbench) 

•  Comments  on  X3D  specification  (plus  Amendment  1  &  Amd  2  proposals)  for  simulation  needs: 
David  Maynard 

•  Meeting/tutorial  at  Web3D  2005  Symposium,  29  March  -  1  April  2005,  Bangor,  Wales,  United 
Kingdom  (UK)  -  Don  Brutzman  http://www.hpv.infonnatics.bangor.ac.uk/s2005 

Future-work  issues  for  discussion: 

•  Support  for  various  coordinate  systems 

•  How  to  apply  DIS  to  Web  Services? 

•  X3D  Specification  Amendment  2  plans 

•  Relationship  to  SISO  DIS  recharter  effort 

•  DIS-lite  and  DIS-plus  development; 

o  addition  of  H-Anim  gesture  PDUs  or  HAnimStreaming  node 
o  general  XSBC  streaming  of  X3D  behaviors,  etc. 

References: 

DIS  component  of  X3D  specification 

http://www.web3d.org/x3d/specifications/ISO-IEC-19775-IS- 

X3DAbstractSpecification/Part01/components/dis.html 

DIS-Java- VRML  working  group  site  and  code  distribution 
http://web.nps.navy.mil/-brutzman/vrtp/dis-java-vrml 

Sourceforge  site:  XSBC  (and  XOM  in  February  2005) 
http://sourceforge.net/projects/xmsf 

Yumetech  Xj3D  extensions  for  DIS  and  picking 
http  ://www  .xj  3  d.  org/ extensions/DIS  .html 
http://www.xj3d.org/extensions/DIS_examples.html 
http://www.xj3d.org/extensions/picking.html 
http://www.xj3d.org/extensions/picking_examples.html 
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3. 1.3.3  Maturity 

Standards  for  Web  services  are  both  rapidly  becoming  established  and  rapidly  evolving  as  the 
commercial  world  invests  enormous  sums  of  money  into  this  approach  to  building  IT  solutions. 
The  DoD  has  opportunity  to  participate  in  the  standards  organizations  to  influence  how  these 
evolve  while  also  creating  strategy  for  their  adoption  and  employment. 

3.1.3.4  Required  Changes 

The  M&S  community  needs  to  continue  to  work  with  the  emerging  GIG  concept  to  ensure  wide- 
scale  interoperability  with  C4I  systems  as  well  as  with  other  simulation  systems.  One  of  the  key 
areas  for  research  is  extension  of  Web  services  capabilities  to  accommodate  data  streaming. 

3. 1.3.5  Timetable  for  Adoption  of  Changes 

Exploration  and  drafting  of  applicable  standards  will  continue  through  FY05  and  the  early  part 
of  FY06.  Target  date  for  submission  of  proposals  to  relevant  standards  bodies  is  mid-FY06. 
Expected  approval  is  late  FY06  to  early  FY07. 

3.1.4  XMSF  Profiles 
3. 1.4.1  Description 

To  create  practical  understanding  of  the  application  of  XMSF  precepts  to  real  products,  SISO 
established  an  XMSF  Profiles  Study  Group  in  September  2003.  The  Study  Group  is  working  to 
determine  the  required  scope  for  XMSF  Profiles  and  to  define  their  structure  and  application. 
The  Study  Group  Terms  of  Reference  (TOR)  document  (Morse,  2003)  states  that  the 
specification  of  XMSF  will  be  in  the  fonn  of  a  collection  of  profiles  detailing  how  to 
interoperate  with  XMSF  compliant  systems.  XMSF  Profiles  SG  progress  was  presented  to  the 
M&S  community  at  the  Fall  2004  Simulation  Interoperability  Workshop. 

The  SISO  XMSF  Profiles  Study  Group  is  actively  defining  formal  technical  specifications  for 
application  of  interoperable  Web-based  technologies  enabling  composable  and  reusable  M&S 
elements,  and  facilitating  enterprise  integration.  XMSF  profiles  will  enable  inter-  and  intra¬ 
domain  interoperability.  The  Study  Group  has  established  that  at  a  macro  level  a  profile  will 
consist  of: 

•  Applicable  Web  technologies  and  protocol  standards 

•  Applicable  data  and  metadata  standards,  including  a  tailoring  of  the  set  of  selected  standards 
(e.g.,  tailoring  of  authentication  standards) 

•  Recommendations  and  guidelines  for  implementation 
o  Composability  guidelines 

o  Technology  application  guidance 

o  Hardware  configuration  recommendations,  requirements,  and  constraints;  e.g.,  network 
bandwidth,  minimum  processing  capability 

o  Software  configuration  recommendations,  requirements,  and  constraints;  e.g.,  browser 
support  for  specific  applications 
o  Specialization  of  design  methodologies 
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Furthermore,  the  Study  Group  has  established  the  following  objectives  for  XMSF  Profiles: 

•  Provide  unambiguous  specification  of  the  interfaces  and  functionality  of  components  of  the 
framework. 

•  Ensure  interoperability  between  existing  and  new  Web-enabled  technologies,  both  within 
M&S  and  in  related  domains. 

•  Provide  the  necessary  metadata  to  facilitate  composability  and  reuse  of  components  across 
multiple  M&S  application  domains. 

•  Facilitate  development  of  new  applications  and  services  that  are  functionally  interchangeable 
with  existing  applications  and  services. 

•  Enable  development  of  new  applications  and  services  that  readily  extend  functionality  for 
continuous  evolution  of  capabilities. 

As  background  research,  the  group  has  examined  the  use  of  profiles  in  other  areas,  such  as 
several  of  the  defined  or  emerging  ISO  standards  and  Web-based  technologies,  including  X3D 
(Extensible  3D  Graphics),  XHTML  (Extensible  HTML),  SMIL  (Synchronized  Multimedia 
Integration  Language),  XHTML+SMIL,  Cascading  Style  Sheets  Level  2  for  mobile  devices, 
Scaleable  Vector  Graphics  (SVG),  XHTML  +  MathML  +  SVG,  WebCGM  (Computer  Graphics 
Metafile)  and  others. 

The  Study  Group  is  currently  preparing  a  Concept  of  Operations  (ConOps)  describing  how  each 
XMSF  stakeholder  develops,  finds,  and  uses  profiles.  Stakeholders  include  the  following  (with 
brief  description  of  their  roles): 

•  Simulation/system  users 

o  Provide  feedback  on  usefulness  and  ease  of  use  of  simulation/system  (developed  in 
accordance  with  profile(s)) 
o  Identify  new  simulation/system  requirements 

•  Simulation/system  developers 

o  Develop/integrate  new  simulations/sy stems  consistent  with  existing  profiles 
o  Identify  compositions  of  profiles 
o  Identify  the  need  for  new  profiles 

o  Develop/integrate  new  simulations/sy  stems  without  an  existing  profile 
o  Develop  profiles  for  new  simulations/sy  stems 

o  Provide  feedback  to  Profile  Community/Working  Group  on  effectiveness  of  profile 
standard 

o  Provide  feedback  to  Profile  Certifying  Authority  on  accuracy  of  individual  profiles 

•  Profile  Community/Working  Group 
o  Develop  profile  standard 

o  Update  profile  standard  based  on  experience  of  simulation/system  developers 
o  Make  recommendations  to  Profile  Certifying  Authority  about  certification  processes  and 
metrics 

•  Profile  Certifying  Authority 

o  Maintain  repository  and  CM  of  approved  profiles 
o  Develop  certification  processes  and  metrics 

o  Ensure  accuracy  and  consistency  of  the  profile  standard  as  it  evolves 
o  Assess  individual  profiles  according  to  the  profile  standard,  and  certification  processes 
and  metrics,  with  a  possible  profile  V&V  role  to  ensure  that  profiles  remain  consistent 


37 


with  the  profile  standard  if/when  it  changes 

•  Profile  Managers  -  advocate  for  profiles  within  a  domain 

o  Negotiate  alignment  of  profiles  where  there  is  a  mismatch  of  nomenclature  or  functional 
overlap 

■  Identify  alternative  implementations  of  capabilities 

■  Identify  aggregate  related  dependencies 
o  Identify  missing  capabilities 

o  Recommend  foundations  and  enhancements  to  the  profile  standard  based  on  user  needs 

■  Identify  existing  domain  standards 

■  Migrate  domain  standards  into  profile 

•  Implementation  Certification  Agents 

o  Certify  that  a  capability  implementation  is  consistent  with  a  profile 

•  Customer  -  e.g..  SPOs  and  Program  Managers 

o  Specify  the  requirement  to  adhere  to  specific  profiles 

Figure  3  provides  an  overview  of  role  relationships  across  these  stakeholders. 

This  effort  is  helping  Study  Group  participants  come  to  grips  with  the  nature  and  purpose  of 
XMSF  Profiles.  To  further  inform  the  activity  of  the  group,  specific  exemplars  are  needed  - 
much  can  be  learned  by  trying  to  describe  the  profile  for  a  particular  application,  even  before  the 
Study  Group  has  fully  defined  how  profiles  should  be  specified. 

3. 1.4.2  Area  of  Applicability 

No  guidelines  currently  exist  for  application  of  XMSF  concepts  to  M&S  system  development 
and  interoperability.  The  XMSF  Profiles,  when  established,  will  provide  this  guidance  to  the 
M&S  community. 
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Figure  3.  Stakeholders  and  Role  Relationships  from  the  XMSF  Profiles  Concept  of 

Operations 

The  XMSF  team  has  attempted  to  identify  many  of  the  core  Web  technologies  that  are 
established  and  emerging,  and  attempted  to  create  a  basis  for  profiling  the  characteristics  of 
particular  applications.  (Blais,  2004)  addressed  part  of  the  definition  of  XMSF  profiles;  namely, 
that  a  profile  consists  of:  (1)  applicable  Web  technologies  and  protocol  standards  and  (2) 
applicable  data  and  metadata  standards.  The  paper  explored  a  profiling  approach  that  identifies 
(1)  an  Interoperability  Profile,  taken  as  the  level  of  interoperability  according  to  the  LCIM 
(Tolk,  2004a);  (2)  an  Implementation  Profile  from  identification  of  Web  technologies  from  the 
Semantic  Web  Services  Stack  (see,  for  example,  (Obrst,  2003));  and  (3)  a  Security  Profile  from 
identification  of  security  implementation  standards  from  the  Web  Services  Security  Stack  (see, 
for  example,  (IBM,  2002)).  These  notions  were  applied  to  two  analytical  combat  modeling 
projects  to  try  to  characterize  their  current  implementation  as  well  as  work  in  progress  to 
incorporate  additional  or  expanded  Web  technologies. 

Association  of  profiles  with  actual  applications  helps  to  distinguish  features  of  the  applications 
that  support  greater  levels  of  interoperability,  providing  both  an  appraisal  of  what  an  application 
can  do  now  and  an  assessment  of  how  it  can  be  modified  to  achieve  higher  levels  of 
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interoperability  in  the  future,  as  may  be  required. 

For  profiles  to  successfully  enable  interoperability  their  initial  content  and  structure  must  be 
agreed  upon.  As  the  underlying  technologies  and  standards  evolve  the  profiles  and  their 
implementations  will  need  to  be  upgraded  in  an  iterative  fashion  to  maintain  interoperability. 
Knowing  what  those  technologies  are  and  how  they  interrelate  facilitates  co-evolution  of  the 
applications  as  underlying  technologies  evolve. 

Of  particular  interest  is  the  possibility  to  use  XMSF  profiles  to  define  M&S  profiles  for  the 
Global  Infonnation  Grid.  In  collaboration  with  the  Army’s  Battle  Command,  Simulation  and 
Experimentation  Directorate  (BCSE,  fonner  AMSO),  an  initial  analysis  was  conducted  which 
will  be  published  in  a  workshop  paper  during  the  Spring  2005  Simulation  Interoperability 
Workshop  in  San  Diego,  CA. 

3. 1.4.3  Maturity 

The  XMSF  Profiles  work  is  proceeding  in  accordance  with  the  plan  from  the  SG  TOR. 
Numerous  exemplar  products  have  been  developed  and  demonstrated  to  help  guide  the 
community  and  provide  a  basis  for  definition  of  profiles  by  the  SG. 

3.1.4.4  Required  Changes 

Next  steps  for  the  SG  include  determining  what  to  use  to  represent/describe/convey  XMSF 
profiles.  Some  considerations: 

•  Need  to  detennine  both  content  and  structure/format 

•  Contents  of  profiles  must  support  the  profile  definition 

•  Contents  of  profiles  must  support  the  roles  of  the  stakeholders 

•  Since  unambiguous  interpretation  is  our  first  objective,  focus  on  technologies  that  support 
automated  methods 

o  Searching 
o  Composability 
o  Integration 

The  work  is  leading  to  refinement  of  technical  requirements  to  be  met  through  the  profiles: 

•  Provide  unambiguous  specification  of  the  functionality  of  components,  and  interfaces  among 
components  of  the  framework 

o  WSDL 

o  Use  fonnal  specification  technologies 
.  UML 

•  DoDAF 

•  Ensure  interoperability  between  existing  and  new  web  enabled  technologies,  both  within 
M&S  and  in  related  domains 

o  Define  XML  schema  for  tagging  standards  (protocol,  data,  metadata)  and  other  profiles 

•  References  to  Reference  FOMs  and  BOMs 

•  References  to  established  metadata  standards  (namespace) 
o  Identify  other  interoperability  technologies  and  standards 

.  HLA 
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•  Defense  Information  Standards  Repository  (DISR)  replaces  the  JTA 
.  SIP  (RFC  3261) 

•  Provide  the  necessary  metadata  to  facilitate  composability  and  reuse  of  components  across 
multiple  M&S  application  domains 

o  Work  with  appropriate  DoD  namespace  managers 
o  Should  we  define  our  own  metadata  tags  to  support  searching? 

•  As  extensions  to  WSDL  to  support  searching? 

•  For  HLA-compliant  simulations,  should  we  try  to  codify  federation  agreements? 

•  See  recommendations  of  data/metadata  subgroup  of  CMSE  workshop,  Simulation 
Interoperability  Workshop  paper  04S-SIW-050,  and  the  RAND  report 

•  Business  Process  Execution  Language  for  Web  Services  (BPEL4WS) 

•  Facilitate  development  of  new  applications  and  services  that  are  functionally  interchangeable 
with  existing  applications  and  services 

o  WSDL 

•  Enable  development  of  new  applications  and  services  that  readily  extend  functionality  for 
continuous  evolution  of  capabilities 

o  Possible  use  of  Resource  Description  Framework  (RDF)  and/or  Web  Ontology  Language 
(OWL)  to  describe  semantics 

3. 1.4.5  Timetable  for  Adoption  of  Changes 

Adoption  will  require  an  extended  process  of  community  building  and  standards  definition.  A 
timeline  for  XMSF  Profiles  standardization  is: 

•  FY05  -  complete  initial  profile  definitions  and  example  instances 

•  FY06  -  SISO  draft  completed 

•  FY07  -  draft  accepted  in  SISO 

3.1.5  XMSF  Overlay  Multicast  and  Internet  Community  Standards 
3. 1.5.1  Description 

The  ability  to  perfonn  many-to-many  multicast  over  an  open  network  is  very  important  to  the 
real-time  distributed  virtual  simulation  (RT-DVS)  community  and  key  to  implementing  XMSF. 
Implementing  end  system  or  overlay  multicast  for  real-time  distributed  simulations  allows  the 
continued  use  of  open  protocols  as  implemented  across  the  Internet.  As  a  result,  RT-DVS  is  no 
longer  dependent  on  consistency  of  network  policy  implementation  across  the  Internet,  Global 
Information  Grid,  etc.  and  supports  the  RT-DVS  community’s  effort  to  move  to  Web  based 
technologies. 

Distributed  virtual  simulations  operating  across  a  network  in  human  time  generate  large  amounts 
of  message  traffic  among  the  computers  hosting  the  simulation  applications.  Efficient 
distribution  of  this  traffic  requires  many-to-many  communications  in  a  dynamic  group 
environment  because  unicast  transmission  among  N  computers  in  the  group  requires  0(N")  total 
message  transmissions,  where  multicast  requires  only  O(N)  (Simon,  et.  ah,  2003).  In  addition, 
this  simulation  environment  may  not  necessarily  be  homogenous,  e.g.  each  simulator  is  likely  to 
be  different  although  they  dynamically  share  common  simulation  objects  over  time.  The  result  is 
that  simulation  objects  may  have  membership  in  multiple  groups  with  each  group’s  membership 
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changing  at  different  rates. 

Distributed  virtual  simulations  also  require  specific  delay  bounds  to  support  the  delivery  of  real¬ 
time,  interactive  visual  and  audio  information  at  human  response  times.  This  environment  can 
be  described  as  a  multiparty  collaborative  environment  running  multimedia  applications.  The 
underlying  networking  environment  needs  to  support  a  large  number  of  participants  dynamically 
joining  and  leaving  the  applications  across  the  myriad  of  public  and  private  networks  that  make 
up  the  Internet.  Because  each  of  these  networks  is  independently  managed,  the  RT-DVS 
applications  cannot  rely  on  the  Internet  to  deliver  the  necessary  QoS  even  where  QoS 
mechanisms  are  deployed.  As  a  result,  networking  real-time  simulators  together  has  seen 
deployment  only  in  specialized  local  area  networks  or  on  private  networks  dedicated  to  the 
simulation  environment.  The  problem  can  be  overcome  by  an  overlay  multicast  protocol 
supporting  efficient,  reliable  multicast  transmissions  over  existing  network  protocols  such  as 
UDP/IP.  This  allows  for  cross-network  operation:  distribution  across  multiple  network 
administrative  domains  found  in  the  Internet. 

3. 1.5.2  Area  of  Applicability 

Up  to  now  it  has  been  necessary  to  design  and  implement  a  private  network  employing  IP 
multicasting  for  any  large  exercise,  evaluation,  or  experiment  that  required  the  efficiency  of 
multicast  for  many-to-many  group  communication.  Effective  with  the  availability  of  XOM,  it 
will  be  possible  to  “turn  on”  multicasting  across  any  combination  of  local  area  networks  that  are 
interconnected  by  Internet  Protocol  service.  The  perfonnance  available  will  of  course  be 
dependent  on  the  underlying  networks.  Experience  to  date  suggests  that  across  networks  such  as 
Internet2  and  DREN,  an  XOM  system  using  the  current  prototype  XOM  Relay  (XOMR) 
prototype  could  support  tens  of  subnets  with  aggregate  group  traffic  up  to  5000  messages  per 
second  and  1  Megabit  per  second,  while  exhibiting  latency  under  100  milliseconds  and  jitter 
under  20  milliseconds.  Scaling  to  higher  traffic  levels  should  be  possible  if  the  load  is 
distributed  across  multiple  multicast  groups,  assuming  the  underlying  network  has  adequate 
capacity.  In  addition,  XOM  can  be  used  with  our  previously  developed  Selectively  Reliable 
Multicast  Protocol  (SRMP)  to  achieve  more  efficient  transmission  of  a  mix  of  reliable  and  best- 
effort  multicast,  a  function  that  is  not  available  elsewhere  in  any  fonn. 


3. 1.5.3  Maturity 

XOM  is  a  new  development,  based  on  overlay  concepts  developed  in  the  networking  research 
community  in  the  past  decade.  Its  applicability  has  been  demonstrated  clearly  and  its  concept  is 
very  basic:  middleware  relay  agents,  deployed  one  per  subnetwork,  cooperate  to  form  an  overlay 
“meta  network”  that  replicates  the  traditional  multicast  tree  and  achieves  network  use  efficiency 
equal  to  IP  multicast.  The  current  XOMR  is  capable  of  supporting  moderate  traffic  levels  (5000 
aggregate  messages  per  second  in  the  multicast  group)  and  soon  will  be  more  operationally 
practical  due  to  enhancement  by  Web  services  for  registry  and  routing  information  distribution. 
However,  reaching  the  maturity  needed  for  broad  Defense  M&S  use  will  require  an  industrial- 
strength  implementation  combined  with  confidence-building  demonstration  applications. 
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3.1.5.4  Required  Changes 

Needed  changes  include  expansion  to  an  industry-academic  development  team  and 
standardization  work,  beginning  in  Web3D  (a  natural  application  community)  and  leading  to 
IETF  or  other  open  network  standards  body  formalization.  It  appears  that  IETF  acceptance  of 
SRMP  will  need  to  be  combined  with  XOM  due  to  the  fact  that  the  Reliable  Multicast  Transport 
Working  Group  has  yet  to  consider  it,  and  that  group  is  due  to  be  terminated  soon,  leaving  no 
immediate  path  to  pursue  SRMP  standardization  within  IETF. 

3. 1.5.5  Timetable  for  Adoption  of  Changes 

FY05  -  initial  industry  team  formation;  early  demonstrations  involving  five  to  ten  sites;  work 
with  Web3D  to  define  a  standardizable  protocol. 

FY06  -  scale-up  to  twenty  sites  and  participate  in  a  major  military  exercise  or  experiment;  work 
with  IETF  to  formalize  an  open  standard. 

3.1.6  Semantic  Web 

3. 1.6.1  Description 

One  of  the  newest  initiatives  in  the  evolution  of  the  World  Wide  Web  (WWW)  is  the 
specification  of  standards  and  technologies  to  create  the  Semantic  Web.  Most  of  today’s  WWW 
is  targeted  primarily  at  human  readers;  the  Semantic  Web  supports  both  human  readers  and 
software  agents  that  can  perform  automated  reasoning,  creating  a  Web  of  knowledge.  The 
Semantic  Web  is  “an  extension  of  the  current  Web  in  which  infonnation  is  given  well-defined 
meaning,  better  enabling  computers  and  people  to  work  in  cooperation”  (Berners-Lee,  et.  ah, 
2001). 

Key  technologies  comprising  the  Semantic  Web  are  summarized  by  the  WWW  Consortium 
(W3C)  in  a  Semantic  Web  Stack  shown  in  Figure  4  (Hennan,  2003)  (Daconta,  et.  ah,  2003). 
Brief  descriptions  of  the  layers  in  the  Semantic  Web  Stack  are  provided  below. 
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Figure  4.  Semantic  Web  Stack 


-Universal  Resource  Identifier  (URI).  Any  resource  on  the  WWW  is  identified  by  a  URL  The 
URI  comes  in  two  forms,  the  familiar  Universal  Resource  Locator  (URL),  commonly  used  for 
web  page  and  web  link  addresses,  and  the  less  common  Universal  Resource  Name  (URN),  used 
to  provide  a  unique  logical  naming  of  any  resource  on  the  WWW  without  regard  to  its  physical 
location. 

-Unicode.  Unicode  provides  a  unique  number  for  every  character,  no  matter  what  the  platform, 
no  matter  what  the  program,  no  matter  what  the  language  (Unicode,  2004).  Unicode  is  required 
by  modem  standards  such  as  XML,  Java,  and  ECMAScript  (JavaScript),  and  is  the  official  way 
to  implement  the  universal  character  set  standard,  ISO/IEC  10646  (ISO/IEC,  1993).  The 
emergence  of  the  Unicode  Standard,  and  the  availability  of  tools  supporting  it,  are  among  the 
most  significant  recent  global  software  technology  trends. 

-XML.  XML  provides  the  ability  to  create  new  vocabularies  to  structure,  describe,  and 
interchange  data,  as  discussed  above.  XML  enables  users  to  add  arbitrary  structure  to  their 
documents  but  says  nothing  about  what  the  structures  mean.  XML  is  a  subset  of  the  Standard 
Generalized  Markup  Language  (SGML),  as  is  HTML,  which  serves  as  a  standard  for  creating 
languages  (Hunter,  et.  ah,  2003).  Whereas  HTML  has  a  fixed  set  of  defined  tags,  XML  provides 
rules  for  creating  an  arbitrary  set  of  tags  by  which  an  agent  (human  or  software)  can  describe 
content  in  a  document.  XML  is  a  clearly  defined  way  to  structure,  describe,  and  interchange 
data  (Altova,  2003).  The  structure  and  content  of  an  XML  document  can  be  specified  by  a 
Document  Type  Definition  (DTD)  or  by  an  XML  schema.  XML  documents  can  be  validated 
against  their  respective  specifications,  as  represented  by  DTDs  or  schemas.  The  XML  Schema 
language  provides  more  detailed  specification  of  the  grammar  of  an  XML  language  through 
range  constraints,  patterns,  and  use  of  XML  namespaces. 
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Since  XML  enables  one  to  describe  data,  XML  documents  themselves  become  data  that  can  be 
described.  Thus,  layers  of  metadata  can  be  written  to  describe  content,  describe  the  description 
of  the  content,  describe  relationships  across  content,  and  so  forth  to  any  level  of  complexity 
needed.  As  we  will  see  shortly,  this  idea  is  a  fundamental  building  block  for  the  Semantic  Web. 

-Namespaces.  XML  Namespaces  provide  a  means  for  distinguishing  an  element  identifier  in 
one  context  (namespace)  from  the  same  element  identifier  in  another  context  (different 
namespace).  Thus,  XML  Namespaces  provide  a  mechanism  for  deconflicting  element  identifiers 
(tag  names)  in  XML  documents,  allowing  multiple  XML  languages  (specified  by  schemas,  for 
example)  to  be  merged  into  the  same  document  without  confusion.  This  means  that  XML 
languages  can  be  defined  for  specialized  purposes  but  combined  when  needed  with  other  XML 
languages  for  more  complete  information.  An  example  would  be  an  XML  language  for  military 
equipment  being  combined  with  an  XML  language  describing  a  military  unit  to  produce  XML 
documents  containing  the  equipment  possessed  by  certain  units.  Both  vocabularies  may  have  an 
element  called  “Name”  (i.e.,  name  of  the  unit,  name  of  the  equipment  item),  but  in  the  combined 
document,  the  usage  is  distinguished  by  the  respective  namespace. 

-XML  Query.  The  hierarchical  structure  of  an  XML  document  and  the  identifiable  element  tags 
and  attribute  names  facilitate  document  search.  The  XML  Query  (XQuery)  project  of  the  W3C 
seeks  to  develop  a  standard  for  querying  XML  documents,  as  well  as  the  next-generation 
standards  for  XML  selection  (XPath2),  XML  serialization,  Full-Text  Search,  a  possible 
functional  XML  Data  Model,  and  a  standard  set  of  functions  and  operators  for  manipulating  web 
data  (XQuery,  2004). 

-XML  Schema.  As  introduced  earlier,  XML  Schema  is  a  XML-based  markup  language 
describing  the  structure  and  constraining  the  contents  of  XML  documents  (Geroimenko,  2004). 

-Resource  Description  Framework  (RDF)  Model  and  Syntax  (RDF  Schema).  RDF  is  an 

XML-based  language  for  representing  infonnation  about  resources  in  the  WWW  (RDF,  2004). 
Resources  are  anything  on  the  Web  that  is  identified  by  a  URL  The  RDF  syntax  expresses  a 
subject-predicate-object  triplet  (equivalently,  also  referred  to  as  an  object- attribute-value  triple), 
so  that  relationships  between  resources  can  be  declared  (i.e.,  we  can  create  class  hierarchies  for 
the  classification  and  description  of  objects).  RDF  provides  a  means  to  express  assertions  that 
form  a  foundation  for  logical  reasoning.  Whereas  RDF  is  a  set  of  rules  for  defining  semantics; 
RDF  Schema  is  a  way  of  creating  vocabularies  (Hjelm,  2001). 

-Ontology.  Ontology  is  a  “formal,  explicit  specification  of  a  shared  conceptualization”  (Gruber, 
1993).  Ontologies  provide  a  “shared  and  common  understanding  of  a  domain  that  can  be 
communicated  between  people  and  heterogeneous  and  widely  spread  application  systems” 
(Fensel,  2001).  An  ontology  provides  a  vocabulary  of  terms  and  relations  with  which  to  model  a 
domain. 

Another  perspective  on  the  Semantic  Web  concept  is  shown  in  the  Ontology  Spectrum  in  Figure 
5  (Daconta,  et.  ah,  2003).  The  Ontology  Spectrum  identifies  various  approaches  to  describing 
data  providing  a  scale  from  weak  semantics  to  strong  semantics.  Technologies  promoted  in  the 
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Semantic  Web  push  the  community  to  higher  levels  of  semantic  representation  so  that  software 
can  achieve  interoperability  at  a  conceptual  level. 


Ontology  Spectrum 
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Figure  5.  Ontology  Spectrum 

VMASC  is  studying  to  what  extent  data  models  based  on  mutual  consensus,  in  particular  the 
C2IEDM,  can  serve  as  an  ontology.  The  study  is  analyzing  the  general  requirements  and 
constraints  for  ontologies  for  unambiguous  information  exchange  and  the  extent  to  which  a 
model  such  as  the  C2IEDM  can  fulfill  these  needs.  In  addition  to  this  graduate  level  evaluation, 
the  Battle  Management  Language  (BML)  efforts  are  dealing  with  similar  questions  for  the 
alignment  of  air  and  land  BML  in  the  joint  context.  NPS  MOVES  is  working  with  the  US  Army 
Engineer  Research  and  Development  Center  (ERDC)  to  examine  various  representations  of 
maneuver  networks  to  establish  a  conceptual  foundation  for  development  of  a  Common 
Maneuver  Networks  ontology  to  enable  simulation  and  C4I  systems  to  interoperate  with 
maneuver  data  for  analysis,  training,  planning,  and  operations  conduct. 

-Rules/Query.  Given  the  ability  to  make  assertions,  rules  can  be  formulated.  Rules  are 
considered  to  be  a  major  issue  in  the  further  development  of  the  Semantic  Web.  They  can  be 
used  in  ontology  languages,  either  in  conjunction  with  or  as  an  alternative  to  description  logics, 
and  they  act  as  a  means  to  draw  inferences,  to  express  constraints,  to  specify  policies,  to 
transform  data,  and  other  operations.  Moreover,  a  rules  layer  provides  a  standard  way  to  query 
and  filter  RDF.  For  example,  RDF  and  RDF  Schema  can  be  considered  at  three  levels  of 
abstraction  (Broekstra,  et.  ah,  2003): 
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•  Syntactic:  as  XML  documents,  can  be  queried  as  discussed  previously,  but  this  approach  is 
not  practical  since  relationships  in  the  RDF  data  model  are  not  apparent  from  the  XML  tree 
structure; 

•  Structure:  as  a  set  of  triples  (object-attribute-value),  a  number  of  query  languages  have  been 
proposed  and  implemented,  but  certain  RDF  Schema  statements  have  been  given  special 
semantics  that  cannot  be  asserted  the  same  way; 

•  Semantic:  as  one  or  more  graphs  with  partially  defined  semantics,  enabling  queries  that  give 
access  to  the  RDF  Schema-specific  contents  of  an  RDF  triplet  and  the  structure  of  the 
subclass  hierarchy. 

• 

-Logic.  The  logic  layer  establishes  a  formal  framework  for  assertions  and  inferences. 

-Proof.  The  logical  framework  provides  the  basis  for  software  to  prove  theorems  about  the 
domain  represented  by  the  ontology. 

-Trust.  The  goal  is  to  establish  a  “web  of  trust”  where  human  and  software  agents  can  interact 
and  exchange  services  and  data  in  a  trusted  environment  (hard  enough  for  humans  to  establish; 
very  challenging  for  software).  The  ability  to  establish  trust  is  built  upon  the  lower  layers  of  the 
stack  and  the  cross-cutting  security  enablers,  Signature  and  Encryption. 

-Signature.  Digital  signatures  are  “encrypted  blocks  of  data  that  computers  and  agents  can  use 
to  verify  that  the  attached  infonnation  has  been  provided  by  a  specific  trusted  source”  (Berners- 
Lee,  et.  ah,  2001). 

-Encryption.  Sensitive  data  can  be  encrypted  so  that  only  the  intended  recipient  is  able  to  read 
the  data.  Confidence  that  sensitive  data  is  protected  and  assurance  that  interactions  are  taking 
place  only  with  intended  agents  are  key  enablers  to  trust. 

Some  of  the  other  abbreviations  in  Figure  5  not  previously  described  are  defined  below  (with 
references  for  the  interested  reader): 

•  ER:  Entity-Relation  model 

.  XTM:  XML  Topic  Maps,  see  (XTM,  2004)  and  (Garshol,  2004) 

•  DAML+OIL:  Defense  Advanced  Research  Projects  Agency  (DARPA)  Agent  Markup 
Language  +  Ontology  Inference  Layer  (OIL);  see  (DAML,  2001) 

•  OWL:  Web  Ontology  Language;  see  (OWL,  2004) 

As  discussed  previously,  SOA  are  rapidly  becoming  the  primary  approach  to  automated  business 
interactions  and  business  process  integration  in  the  commercial,  government  and  military  arenas. 
Web  services  and  service-oriented  architectures  “are  going  to  fundamentally  change  the  way  we 
build  our  internal  systems  -  the  information  systems  that  support  our  organizations  -  and  how 
our  internal  systems  interact  with  external  systems”  (Barry,  2003).  However,  while  Web 
services  define  fonnal  interface  contracts  describing  the  message  syntax,  they  do  not  address  the 
semantics  issue;  that  is,  the  meaning  of  the  exchanged  data  is  not  formally  described 
(Zimmermann,  et.  ah,  2003).  For  agent-to-agent  applications  to  automate  solutions  to 
interoperability  problems,  they  will  need  to  have  an  understanding  of  the  data  being  exchanged; 
not  just  what  it  is,  but  what  can  be  done  with  it.  This  realization  has  spawned  research  in  a 
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blending  of  Web  services  with  the  Semantic  Web,  denoted  as  Semantic  Web  Services. 

3, 1.6.2  Area  of  Applicability 

Military  modeling  and  simulation  (M&S),  together  with  Command,  Control,  Communications, 
Computers  and  Intelligence  (C4I)  systems,  continue  to  represent  extremely  challenging  areas  of 
computer  application  today.  Few  applications  hold  such  importance  in  terms  of  material  and 
human  costs  than  the  strategic,  operational,  and  tactical  systems  used  for  military  acquisition, 
training,  analysis,  planning,  rehearsal,  execution,  and  after-action  assessment. 

Two  overarching  challenges  to  military  M&S  include: 

•  Interoperability:  The  capability  of  a  system  (e.g.,  simulation)  to  automatically,  without 
human  intervention,  provide  services  to  and  accept  services  from  other  systems,  and  to  use 
the  services  so  exchanged  to  enable  the  systems  to  work  together  to  achieve  a  desired 
outcome  (adapted  from  (MSMP,  2004)). 

•  Composability:  The  capability  to  select  and  assemble  reusable  simulation  components  in 
various  combinations  into  software  systems  to  meet  user  requirements  (Petty,  2004). 

An  example  of  a  specific  challenge  spanning  both  of  these  overarching  challenges  is  Rapid 
Scenario  Generation.  Sub-objective  1.6  (Automating  M&S  Systems  Support)  of  the  Defense 
Modeling  and  Simulation  Office  (DMSO)  Modeling  and  Simulation  Master  Plan  states  the 
requirement  as:  “Improve  the  automated  workflow  and  support  of  M&S  Systems  (e.g.,  rapid 
database  development).”  (MSMP,  2004)  Rapid  Scenario  Generation  is  the  ability  to  find  and 
prepare  information  and  materials  describing  a  battlespace  to  support  training,  analysis,  or 
mission  planning  within  compressed  time  frames  (particularly  for  mission  planning)  and  based 
on  operational  documents  (e.g.,  training  requirements,  problem  statements,  or  OpOrders, 
respectively).  There  are  numerous  issues  relating  to  how  the  necessary  information  (terrain, 
maps,  forces,  assets,  behaviors,  characteristics,  weather,  etc.)  is  identified,  posted,  discovered, 
accessed,  and  composed  to  form  a  full  battlespace  representation  for  a  particular  use,  including 
as  input  data  to  a  simulation  or  C4I  system.  The  Rapid  Distributed  Database  Development 
(RD3)  is  a  new  program  addressing  this  specific  challenge  (RD3,  2004). 

Existing  and  emerging  Web-based  technologies  are  showing  the  ability  to  achieve  world- wide 
scalability,  changing  the  computational  environment  “from  single  isolated  devices  to  entry  points 
into  a  worldwide  network  of  infonnation  exchange  and  business  transactions”  (Fensel,  2001). 
This  is  currently  happening  at  a  fairly  mechanistic  level  -  the  next  great  technical  leap,  as 
always,  will  be  the  ability  for  software  to  automate  routine  processes.  The  enabler  for  the  next 
technological  leap  on  the  Web  is  the  Semantic  Web: 

“To  date,  the  Web  has  developed  most  rapidly  as  a  medium  of  documents  for  people  rather 
than  for  data  and  information  that  can  be  processed  automatically.  The  Semantic  Web  aims 
to  make  up  for  this.”  (Berners-Lee,  et.  al.,  2001) 

In  the  M&S  domain,  emerging  Semantic  Web  technologies  offer  opportunities  to  dramatically 
improve  composability  of  functional  capabilities  and  interoperability  of  systems,  including 
interoperability  between  M&S  and  operational  C4I  systems. 
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Model  Based  Data  Management 

In  (Tolk,  2004c),  the  author  proposes  use  of  a  reference  data  model  and  describes  Model  Based 
Data  Management  (MBDM)  activities  that  need  to  be  performed  to  map  data  across  software 
services;  namely  (refer  to  that  paper  for  details): 

•  Extension  of  property  values 

•  Enhancement/refinement  of  property  values 

•  Different  grouping  of  property  values 

•  Extension  of  propertied  concepts 

•  Enhancement/refinement  of  propertied  concepts 

•  Different  grouping  of  propertied  concepts 

•  Extension  of  associated  concepts 

•  Enhancement/refinement  of  associated  concepts 

These  activities  provide  a  roadmap  for  development  of  automated  support  to  the  cognitive  effort 
needed  to  perform  the  activity.  The  key  issue  here  is  semantic  mapping  across  diverse  systems. 
Clearly,  the  simplest  notion  is  for  all  systems  to  use  the  same  knowledge  structures  and 
algorithms  to  achieve  complete  conceptual  interoperability.  However,  just  as  the  idea  of  a  single 
human  language  has  never  been  achievable,  a  single  C4I/M&S  language  is  not  practical  as 
concepts  and  approaches  rapidly  evolve  to  address  changing  operations  and  the  ever-changing 
threat.  More  reasonable  is  creation  of  an  extensible  capability  for  diverse  C4I/M&S  languages 
to  be  semantically  interchanged  through  relationships  to  top-level  concepts  for  the  domains  of 
interest  (upper  ontologies).  Any  approach  to  semantic  interoperability  needs  to  enable  even  the 
top-level  concepts  to  adapt  and  evolve  over  time.  The  ideas  of  MBDM  are  now  tool  supported 
(e.g.,  using  Altova  products  XML  Spy  and  MapForce)  and  were  applied  within  the  BML 
projects  “Extensible  Battle  Management  Language  (XBML)”  and  “Air  Operations  Battle 
Management  Language  (AO  BML)”  as  alternatives  to  the  solutions  implemented  by  the  industry 
partners  Atlantic  Consulting  Services,  Inc.  (ACS)  and  Gestalt,  LLC.  C2IEDM  web  services 
developed  for  information  storage  and  data  mediation  use  MBDM  to  map  XML  interfaces  to  the 
C2IEDM  tag  set  as  defined  for  the  coalition  namespace  in  the  DoD  XML  Repository  and  to  store 
and/or  retrieve  information  into/from  a  MySQL  C2IEDM  compliant  database,  which  can  be 
accessed  via  web  services. 

The  C4I-M&S  Reference  Object  Model  (CROM)  effort  over  the  past  few  years  has  been 
working  toward  an  alignment  of  C4I  and  M&S  data  models,  leading  to  description  of  portions  of 
a  C4I  object  model  using  the  C2IEDM.  While  an  important  early  step,  work  is  needed  to  push 
the  semantic  modeling  further  up  the  ontology  spectrum  than  the  CROM  efforts  to  date  by 
moving  from  UML  representations  to  ontological  representations  using  emerging  standards  such 
as  OWL. 

In  (Blais  and  Lacy,  2004),  the  author  describes  a  simple  example  of  the  nature  of  the  problem  by 
considering  the  representation  of  minefields  in  the  OneSAF  Objective  System  (Henderson  and 
Granger,  2001)  abd  C2IEDM.  This  example  deals  with  a  conceptual  level  of  mapping  -  how  the 
data  models  align  (or  don’t  align).  Another  level  of  mapping  is  at  the  instance  level  -  how 
specific  data  aligns  (or  doesn’t);  i.e.,  determining  that  a  particular  item  in  one  data  base 
corresponds  to  a  particular  item  in  another  data  base.  Both  are  critical  issues  to  be  addressed 
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through  Semantic  Web  approaches.  Humans  are  able  in  most  cases  to  perform  data  mappings 
across  representations,  although  sometimes  with  great  difficulty.  The  new  challenge  is  to 
provide  enough  meta-information  about  the  data  to  enable  software  to  be  able  to  automatically 
perform  these  mappings.  Evolution  of  the  Semantic  Web  is  addressing  such  needs. 

DMSO  M&S  Objectives 

The  DoD  Modeling  and  Simulation  Master  Plan  (MSMP)  previously  cited  presents  key 
challenges  that  need  to  be  addressed  to  achieve  long-tenn  solutions,  including: 

•  E5.7.2.2.  M&S  models,  simulations,  data,  information,  and  resources  are  hard  to  find,  access, 
and  use. 

•  E5.7.2.3.  Barriers  to  the  effective  use  of  M&S  resource  repositories  such  as  lack  of 
unambiguous  content  description  standards,  marking  standards,  incentives  to  provide  and 
maintain  infonnation,  and  government  ownership. 

•  E5.10.1.  Consistent,  unambiguous  interchange  capabilities  to  support  dynamic  interactions 
and  interdependencies  of  humans,  systems,  and  the  disparate  elements  of  the  natural 
environment. 

The  MSMP  also  identifies  a  number  of  DoD  M&S  objectives  relevant  to  Semantic  Web 
research: 

•  E3.1.1.5.  Sub-objective  1.6:  Automating  M&S  Systems  Support.  Improve  the  automated 
workflow  and  support  of  M&S  systems  (i.e.,  rapid  database  development). 

•  E3. 1 .2.3.1 .  Establishing  standard  taxonomies,  ontologies,  and  common  object  classes  (e.g., 
individual  equipment,  vehicles,  aircraft,  missiles)  for  systems  FoS  (Families  of  Systems),  and 
SoS  (Systems  of  Systems)  representation. 

•  E. 3. 1.2.4. 6.  Establishing  a  system  to  publish  information  about,  search  for,  share,  and  apply 
distributed  simulation  environments. 

•  E3. 1 .4.2.3.  Establishing  a  readily  accessible  information  resource  that  includes,  but  is  not 
limited  to,  applications,  algorithms,  protocols,  standards,  and  data  sets. 

•  E3. 1 .5.2.4.  Develop  the  tools  and  underlying  infrastructure  to  rapidly  and  accurately  identify, 
access,  acquire,  collect,  analyze,  synthesize,  generate,  and  disseminate  unclassified  and 
classified  scientific,  technical,  and  operational  support  information  required  to  support 
modeling  and  simulation  on  a  worldwide  basis. 

•  E3. 1 .5.3. 1 .  Publish,  find,  and  access  distributed  simulation  capabilities. 

These  challenges  and  objectives  fall  within  the  realm  of  Semantic  Web  research  as  they  involve 
the  description  and  discovery  of  Web-based  (open  or  military,  classified  or  unclassified) 
resources. 

Rapid  Distributed  Database  Development  (RD3) 

The  Rapid  Distributed  Database  Development  (RD3)  program  has  been  initiated  to  address  many 
of  the  MSMP  objectives  identified  above.  RD3  envisions  an  integrated  system  for  identifying, 
collecting,  manipulating,  storing,  and  retrieving  data  in  a  usable  form  to  support  Joint 
requirements  for  planning,  training,  mission  rehearsal,  and  experimentation. 
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It  is  recognized  that  DoD  is  rapidly  undergoing  an  infonnation  transformation,  promoting  the  use 
of  Web  technologies  such  as  XML  for  describing  information  and  Web  Services  for  creating 
environments  for  business  process  and  application  access-on-demand.  Much  work  has  been 
done  and  continues  to  be  done  in  describing  scenario  content  in  XML  representations,  such  as 
the  scenario  description  language  used  by  the  OOS,  employment  of  the  C2IEDM  as  a  common 
representation  for  data  exchange  across  C4I  systems  and  simulation  systems,  and  Battle 
Management  Language  (BML)  for  unambiguous  expression  of  plans  and  orders  for 
understanding  by  humans  and  software  (Hieb,  2004).  Furthermore,  recent  work  takes  the 
representations  to  higher  ontology  levels  (refer  to  the  ontology  spectrum  shown  earlier),  moving 
beyond  XML  and  XML  schema  representations  to  descriptive  layers  that  will  enable  software  to 
perform  reasoning  on  the  data,  setting  the  stage  for  automation  of  processes  that  have  been 
heavily  human-centric  in  the  past;  in  particular,  see  (Lacy  and  Henninger,  2003)  and  (Lacy  and 
Gerber,  2004). 

Research  has  been  proposed  focusing  on  determining  descriptive  techniques  that  will  enable 
software  to  reason  from  structured  scenario  descriptions  to  discover  and  assemble  web-based 
resources  appropriate  for  the  planning,  training,  mission  rehearsal,  or  experimentation  objective 
at  hand.  This  requires  research  at  both  ends  of  the  process  -  description  of  the  resources 
themselves  for  publication  in  the  web  environment  and  identification  of  the  resources  in  the 
scenario  descriptions  in  such  a  way  that  the  appropriate  resources  can  be  found  and  assembled 
automatically  by  software. 

The  RD3  database  production  process  exhibits  a  need  for  strong  semantics  representation  across 
various  activities.  For  example,  Event  Planners  need  to  be  able  to  describe  the  situation  and 
scenario  in  a  form  (e.g.,  XBML  taken  to  a  higher  level  of  the  ontology  spectrum)  that  can  be 
used  by  software  to  assist/automate  operations  perfonned  by  the  Database  Analysts  at  the  next 
level  in  the  process.  Strong  semantics  are  needed  to  support  the  process  of  creating  the 
integrated  source  data  through  correction,  alignment,  merging,  correlation,  and  analysis.  The 
authoritative  source  data  will  likely  reside  on  widely  distributed  resources  on  the  World  Wide 
Web  and  future  military  classified/unclassified  equivalents  (i.e.,  employing  identical  standards 
and  technologies).  Resource  publishing  and  discovery  will  be  enabled  by  Semantic  Web 
research  in  progress. 

For  automation  of  the  assembly  process,  there  has  to  be  explicit  or  inferable  relationships  across 
the  resources  and  the  event  specification.  For  example,  the  scenario  definition  may  indicate  a 
locale  for  the  operation  and  the  forces  involved.  The  assembly  software  must  have  sufficient 
ontological  information  to  be  able  to  infer  the  resolution  of  terrain  or  weather  data  needed  and 
possibly  the  level  of  representation  of  the  forces  that  meets  the  needs  of  the  event  (i.e.,  force 
aggregation  at  some  hierarchy  level  based  on  the  event  audience/participants).  To  assist  Event 
Planners  in  identifying  and  obtaining  the  precise  resources  needed  to  populate  the  event 
specification,  software  must  be  able  to  make  inferences  as  to  the  resources  needed  to  meet  the 
requirements  of  the  event.  Whereas  the  event  specification  may  describe  classes  of  infonnation 
needed,  software  needs  to  make  decisions  regarding  the  actual  data  and  services  instances  that 
will  be  accessed,  collected,  assembled,  and  possibly  transformed  (e.g.,  for  use  in  a  specific 
simulation). 
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In  all  cases,  well-defined  semantics  across  the  several  layers  of  the  problem  description  are 
needed  to  provide  unambiguous  content  description  that  can  be  operated  on  by  software.  One 
can  envision  various  ontologies  being  involved  in  the  scenario  description  process;  e.g.,  one  (or 
more)  describing  the  natural  environment,  one  (or  more)  describing  military  and  non-military 
forces  to  be  represented  in  the  scenario,  one  (or  more)  describing  weapon  characteristics,  one  (or 
more)  describing  time  and  setting  of  the  scenario,  and  so  on.  A  challenge  to  be  faced  is  making 
ontologies  interoperable  through  ontology  mappings;  i.e.,  matching  corresponding  concepts  in 
whole  or  in  part  (Burstein,  2004). 

It  may  be  possible  to  consider  such  limited  scope  domain  ontologies  as  parts  of  a  larger  whole 
that  is  expressed  at  a  higher  level  of  abstraction,  possibly  derived  from  a  foundational  ontology 
(a  conceptualization  that  contains  specifications  of  domain  independent  concepts  and  relations 
based  on  formal  principles  derived  from  linguistics,  philosophy,  and  mathematics).  (Mika,  et.  al, 
2004)  Thinking  long-term,  tying  the  abstraction  of  a  scenario  into  common  structures  such  as 
the  Descriptive  Ontology  for  Linguistic  and  Cognitive  Engineering  (DOLCE)  (Gangemi,  2003) 
or  the  Suggested  Upper  Merged  Ontology  (SUMO,  2004)  permits  the  scenario  concepts  to  cross 
over  into  a  broader  domains  of  application.  One  application  may  be  military  scenarios  playing  a 
role  in  a  larger-scale  political  “game”  in  which  the  planned  military  operation  will  influence 
diplomatic  planning  and  actions. 

Recommended  Semantic  Web  activities  in  RD3  include: 

•  Investigate  current  and  proposed  approaches  to  formalizing  the  situation  and  scenario 
definition  (event  specification).  Propose  and  design  higher  ontology  descriptions  as  needed 
to  enable  software  to  reason  about  the  data  requested. 

•  Investigate  current  and  proposed  approaches  to  formalize  the  description  of  resources. 
Consider  Semantic  Web  research  leading  toward  the  “Web  of  trust”  in  addition  to 
informational  aspects  of  the  resource  description  (e.g.,  detennining  if  a  posted  resource  truly 
represents  what  its  description  implies).  As  needed,  propose  and  design  descriptions  of  the 
resources  that  promote  discovery  and  application. 

•  Propose  and  design  ontology  layers  and  inter-layer  mappings  that  may  be  needed  to  enable 
software  to  automatically  identify  resources  from  the  event  specification. 

•  Track  developments  in  the  Semantic  Web  community  for  application  to  the  research. 

3. 1.6.3  Maturity 

Foundational  standards  are  well  established;  others  are  becoming  more  solid  as  the  community 
focuses  on  the  Semantic  Web  initiative.  A  recent  initiative  in  Europe  called  the  Semantic  Web 
for  Advanced  Development  -  Europe  (SWAD-Europe)  has  provided  “thousands  of  developers” 
with  tools  to  create,  store,  and  view  Semantic  Web  data,  indicating  the  rapid  adoption  of  the 
concepts  by  developers  world-wide.  (Miller,  2004)  The  challenge  is  community  education 
together  with  identification  of  appropriate  standards,  techniques,  and  tools  to  rapidly  introduce 
the  capabilities  into  ongoing  M&S  programs. 

3.1.6.4  Required  Changes 

In  parallel  with  ongoing  WWW  developments,  the  M&S  community  in  recent  years  has  initiated 
efforts  to  detennine  how  the  enormous  investment  in  Internet  and  Web  technologies  can  be 
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exploited  for  military  M&S  purposes.  The  XMSF  project  is  providing  the  technical  basis  for 
transformational  interoperability  via  XML  data  and  messaging  interchange,  profiles,  and 
recommended  practices  for  Web-based  M&S.  Broad  technical  interoperability  is  enabled  by 
open  standards,  XML-based  markup  languages,  Internet  technologies,  and  cross-platform  Web 
services  supporting  diverse  distributed  M&S  simulation  applications. 

In  the  Technical  Challenges  workshop  in  2002,  the  XMSF  project  acknowledged  that 
development  of  ontologies  as  a  basis  of  meaning  is  a  fundamentally  difficult  area  that  has  seen 
much  research  progress  in  recent  years  as  part  of  the  W3C’s  Semantic  Web  (Brutzman,  et.  al., 
2002).  The  first  requirement  in  the  area  of  ontologies  is  to  allow  definition  and  approval  of 
complementary  taxonomies  that  can  be  applied  across  multiple  XMSF  application  domains. 

This  will  allow  for  the  consistent  classification  of  data  and  services  via  precise  vocabularies.  A 
subsequent  requirement  is  to  establish  consensual  common  meaning.  It  does  not  suffice  for  there 
to  be  agreed-upon  meaning  within  a  group,  but  to  be  truly  useful,  there  needs  to  be  a  mechanism 
for  defining  the  equivalence  of  tenns  between  groups  (ontology  mapping).  This  will  allow  for 
both  extensibility  and  for  interoperability.  The  Defense  Advanced  Research  Project  Agency 
(DARPA)  Agent  Markup  Language  (DAML)  project  has  established  an  ontology  repository  for 
common  service  representations  (DAML,  2004).  For  XMSF,  RDF  and  OWL  are  of  particular 
interest  as  applicable  standards  for  ontology  expression.  In  practice,  the  NATO-developed 
C2IEDM  information-exchange  data  model  is  being  exploited  for  tactical  operations.  It  will  be 
particularly  interesting  to  consider  the  implications  of  ontologies  like  C2IEDM  that  help  to 
establish  commonalities  between  services  and  coalition  partners.  Development  of  effective 
ontologies  for  military  operations  orders  (which  contain  tactical  versions  of  the  “who,  what, 
when,  where  and  how”  of  an  operation)  is  a  strategically  important  application  area  deserving 
dedicated  further  work. 

Semantic  Web  concepts  and  standards  can  be  addressed  in  XMSF  Profiles  to  assist  the  M&S 
community  in  integrating  these  powerful  techniques  into  their  existing  and  emerging  systems. 
The  XMSF  profiling  work  can  be  taken  to  the  next  level  of  detail  by  not  just  identifying  what 
Web-based  technology  is  being  employed,  but  by  providing  characterization  of  how  the 
technology  is  being  employed.  For  application  of  Semantic  Web  concepts,  characterization  of 
the  Implementation  Profile  can  include  further  detail  about  the  position  of  the  application  along 
the  ontology  spectrum,  leading  to  further  detail  identifying  registered  schema,  namespaces,  or 
ontologies  employed  as  well  as  modeling  methodology  and  tools  used.  This  information  alone 
reveals  a  wealth  of  insight  into  opportunities  to  interoperate  with  the  subject  application. 
Furthermore,  XMSF  profiles  should  be  expressed  with  sufficient  semantic  content  to  enable 
software  to  compare  profiles  and  make  inferences  regarding  the  level  of  interoperability  that  can 
be  achieved  between  systems  described  by  those  profiles. 

3. 1.6.5  Timetable  for  Adoption  of  Changes 

Initial  efforts  can  be  taken  in  current  development  of  emerging  systems  (e.g.,  OneSAF  Objective 
System,  COMBATXXI)  to  create  a  better  foundation  for  incorporation  of  Semantic  Web  concepts; 
namely,  to  advance  the  level  of  data  modeling  to  representations  in  RDF  at  a  basic  level  and 
OWL  at  a  more  sophisticated  level.  The  community  cannot  afford  to  proceed  with  delivery  of 
these  new  systems  and  be  faced  again  with  future  retro-fitting  to  provide  needed  interoperability 
capabilities.  Implementations  that  are  already  modeled  to  the  level  of  relational  models,  XML 
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schema,  and  Entity-Relation  Diagrams  can  readily  be  converted  to  RDF  notation.  Work  is 
needed  to  provide  automated  tools  to  facilitate  this  process  to  the  fullest  extent  possible. 

Continued  research  and  application  of  Semantic  Web  technologies  are  fundamental  to  further 
automation  of  processes  to  meet  today’s  primary  challenges  to  military  modeling  and  simulation. 

3.2  Experimentation  and  Demonstrations 

Under  XMSF  tasking,  the  Partners  planned  and  coordinated  a  show  floor  booth  (#2249)  at  the 
2004  Interservice/Industry  Training,  Simulation,  and  Education  Conference  (I/ITSEC)  in 
Orlando,  FE  to  provide  presentations  and  demonstrations  of  XMSF  relevant  technologies  and 
capabilities  to  the  community.  Booth  participants  featured  XMSF  partners  and  contributors 
George  Mason  University,  Aniviza,  Yumetech,  Media  Machines,  and  the  Web3D  Consortium. 

In  addition  to  the  principal  XMSF  booth,  XMSF  Partners  were  located  at  the  Defense  Modeling 
and  Simulation  Office  (DMSO)  booth  (#530),  ODU/VMASC  booth  (#2418),  and  SAIC  booth 
(#2605).  Other  contractors  working  with  the  XMSF  project  also  appeared  on  the  show  floor, 
including  Vcom3D  (#243)  and  Planet  9  Studios  (#1 122). 

While  the  majority  of  the  cost  was  provided  by  DMSO  under  XMSF  project  funding, 
NAVMSMO,  MOVES  Institute  Delta3D  project,  and  NPS  Distance  Fearning  Resource  Center 
(DFRC)  made  contributions  to  help  offset  the  overall  cost.  The  Delta3D  project  is  integrating 
open  source  software  to  create  an  open  source  game  engine  for  use  in  military  developments, 
principally  relating  to  networked  virtual  environments  for  training  systems.  DFRC  is  engaged  in 
development  and  delivery  of  military  education  through  online  instruction. 

In  addition  to  DMSO,  various  portions  of  the  systems  and  capabilities  demonstrated  at  the 
conference  were  supported  by  the  following  sponsors:  Joint  Advanced  Distributed  Fearning  Co- 
Faboratory  (JADE  Co-Fab),  Naval  Air  Systems  Command  (NAVAIR),  Defense  Threat 
Reduction  Agency  (DTRA),  USAF  Joint  Synthetic  Battlespace  (JSB),  Joint  Forces  Command 
(JFCOM)  J9,  OPNAV  Assessment  Division  (N81),  Naval  Undersea  Warfare  Center  (NUWC), 
U.S.  Army  Engineer  Research  and  Development  Center  (ERDC),  U.S.  Army  TRADOC  Analysis 
Center  Monterey  (TRAC-Monterey),  Sonalysts,  Inc.  and  Web3D  Consortium. 

Presentations  and  demonstrations  provided  in  the  XMSF  booth  at  I/ITSEC  included: 

Extensible  Modeling  and  Simulation  Framework  (XMSF):  Overview  of  the  project 
objectives  and  achievements  (Dr.  Don  Brutzman,  NPS  MOVES  Institute) 

Extensible  Battlespace  Management  Language  (XBML)  and  XMSF  Overlay  Multicast 
(XOM)  -  refer  to  Sections  4  and  5  of  this  document  for  details  (Dr.  J.  Mark  Pullen,  GMU) 

Xj3D:  Open  Source  Implementation  of  the  X3D  Graphics  Language  (Alan  Hudson  and 
Justin  Couch,  Yumetech,  Inc.) 

Online  Mentors  for  Language  Training  and  Cultural  Familiarization  (Jeffrey  Weekley, 

MOVES  Institute  Research  Associate  and  Computer  Science  Masters  student 

Dr.  Ed  Sims,  Chief  Technology  Officer,  Vcom3D,  Inc.  and  Dr.  Luba  Grant,  Defense 
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Language  Institute  (DLI)) 

Scenario  Authoring  and  Visualization  for  Advanced  Graphical  Environments 

(SAVAGE):  On-Line  Library  of  X3D  Military  Models  and  Authoring  Tools  (Jeffrey 
Weekley,  NPS  and  CS  Masters  student) 

Anti-Terrorism  /  Force  Protection  (AT/FP)  Planning  Tool  (Jeffrey  Weekley) 

Semantic  Interoperability:  Data  Mapping  and  Ontology  Development  (Curtis  Blais,  NPS 
MOVES  Institute  Research  Associate  and  MOVES  Ph.D.  student) 

Combat  Model  Interoperability  using  Web  Services  and  Discrete  Event  Simulation 
(DES)  Simkit  Library:  N81-sponsored  Project  to  Transform  Analytical  Modeling  (John 
Ruck  and  Ed  Bryla,  Rolands  &  Associates  Corporation) 

Visual  Simulation  Toolkit  (Viskit):  Graphical  User  Interface  for  Rapid  Simulation 
Development  (Rick  Goldberg,  Aniviza) 

Autonomous  Underwater  Vehicle  (AUV)  Workbench:  Open  Standards  3D  Visualization 
and  Physics-Based  Modeling  (CDR  Duane  Davis,  USN,  NPS  Computer  Science  Ph.D. 
student) 

Sonar  Visualization  for  Multi-Platform  Net-Centric  Undersea  Warfare  (CDR  Duane 
Davis) 

NPS  Interactive  Web-Based  Media  Elements:  Web-based  exercises  and  animations 
for  NPS  online  course  modules  (Kari  Miglaw,  OCL  NPS,  Dale  Courtney,  NPS,  Ann  Igoe, 
DLRC  (OCL  NPS),  Dianna  Beardslee,  DLRC  (OCL  NPS)) 

Flux:  Reusable  Modeling  &  Simulation  Components  Based  on  Open  Standards  (Tony  Parisi, 
President,  Media  Machines) 

Additional  presentations  and  demonstrations  were  provided  in  the  partner  booths  at  I/ITSEC,  in 
particular: 

XBML/AO  BML:  C2IEDM  based  infonnation  exchange  in  support  of  Battle  Management 
Language  efforts  for  land  and  air  forces  (VMASC  booth) 
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4  XMSF  OVERLAY  MULTICAST 


4.1  Introduction 

Growing  demand  for  use  of  web-based  services  in  large  scale  real-time  distributed  simulation 
virtual  simulation  (RT-DVS)  systems  and  other  real-time  applications  is  fueling  extensive 
research  into  overlay  multicast  protocols.  These  applications  demand  Quality  of  Service  (QoS) 
and  many-to-many  multicast  services  that  are  not  available  in  underlying  Internet  services  today 
and  are  not  likely  to  be  offered  as  an  open  network  service  in  the  near  future.  This  section 
describes  the  requirements  specification  and  proposed  design  of  an  overlay  multicast  protocol 
designed  to  support  many-to-many  multicast  for  RT-DVS  applications,  Extensible  Modeling  and 
Simulation  Framework  (Brutzman,  et.  ah,  2002)  Overlay  Multicast  (XOM). 

We  define  the  overlay  multicast  middleware  as  the  XOM  Relay  (XOMR)  where  relay  implies 
forwarding  of  messages  to  designated  destinations  from  authorized  sources.  XOMR  is  an  overlay 
multicast  protocol  designed  to  support  efficient,  reliable  many-to-many  multicast  transmissions 
on  top  of  existing  network  protocols  such  as  UDP/IP  for  real  time  distributed  visual  simulations. 
It  is  based  on  the  notion  of  a  multicast  host  which  controls  all  aspects  of  group  communications 
as  a  service  to  supported  applications. 

Visual  space  management  in  real-time  distributed  simulation  and  supporting  communications 
systems  are  evolving  toward  Web  based  services  and  XML  tagged  object  characteristics.  The 
throughput  required  for  communicating  object  status  updates  is  potentially  extremely  large, 
consisting  of  thousands  of  updates  to  simulation  objects  per  second.  Receivers  within  a  group 
must  be  able  to  support  a  large  number  of  simultaneous  receivers  per  transport  group  with  good 
scalability.  A  typical  receiver  set  could  be  required  to  support  objects  on  the  order  of  1,000  - 
10,000  simultaneous  objects  per  group,  or  even  more.  These  object  updates  typically  have 
packet  sizes  around  100  bytes  without  tag  or  other  protocol  overheads.  RT-DVS  are  run  on 
heterogeneous  set  of  workstations  with  differing  processing  and  display  capabilities,  traveling 
over  a  heterogeneous  network  with  capacities  varying  by  many  orders  of  magnitude  between  the 
initial  down  link  and  the  slowest  end  user. 

The  simplest  syntax  definition  for  the  protocol  is  that  a  message  m  is  sent  by  process  p  and  the 
reception  of  m  is  by  process  q  at  one  to  many  recipients.  In  order  to  add  a  level  of  QoS,  by 
queueing  algorithm,  the  XOMR  provides  for  the  arriving  of  m  at  an  incoming  channel  from  the 
application  interface  and  provides  for  queuing  on  the  sending  side  to  the  network,  by  process  p. 
The  remainder  of  this  document  provides  the  following  definitions  for  the  XOMR: 

•  The  service  requirement/specification — what  service  is  provided 

•  Assumptions  about  the  environment  in  which  the  XOMR  protocol  must  perform 

•  Specification  of  the  XOMR  protocol  with  a  summary  of  the  key  routing  and  control 
procedures/rules 

4.2  XOMR  Design  Goals 

The  XOMR: 
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•  Should  not  require  support  from  routers  or  operating  systems  in  order  to  preserve 
ubiquitous  deployment. 

•  Should  be  compatible  with  evolving  IP  and  Multiprotocol  Label  Switching  (MPLS) 
multicast  services  as  they  are  deployed  in  the  Internet  and  be  able  to  use  these  services 
automatically  in  the  underlying  networks  as  they  become  available. 

•  Uses  central  registry  service  and  the  location  of  the  registry  service  should  not  impact 
overall  perfonnance  of  the  XOMR. 

•  Will  be  self  organizing  in  the  sense  that  configuration  is  limited  to  selecting  a  registry. 

•  Uses  layered  design  to  indicate  the  logical  structure  of  the  XOMR  protocol  by  separating 
tasks.  Define  the  problem,  the  service  to  be  performed  at  every  layer,  the  external 
functionality,  and  the  internal  functionality. 

•  Uses  routing  middleware  that  is  both  scalable  and  decentralized,  e.g.,  not  dependent  on  a 
central  or  root  services  for  routing  functionality. 

•  Is  based  on  standards  and  portable  abstractions  of  the  system  with  network-specific 
advantages  including  scalability,  fault  tolerance,  and  resource  availability  easily  utilized 
without  any  concerns  about  their  underlying  infrastructure  and  resources 

•  Transmission  errors  are  handled  at  a  higher  layer  such  as  using  SRMP  or  at  an 
application  layer. 

•  Uses  system  aware  messaging  so  that  changes  in  system  status  can  proactively  result  in 
network/application  adaptation 

•  Run  time  environment  can  support  multiple  resources  scalably 

•  Is  able  to  deliver/manage  QoS  to  multiple  simulation/applications 

•  Employs  mechanisms  to  adapt  and  efficiently  use  system  resources 

•  Uses  application  knowledge  of  DVS  to  tailor  design  and  implementation 

•  Uses  local  algorithms  to  collectively  achieve  a  desired  global  effect.  Example:  Some 
form  of  explicit  congestion  notification  could  be  used  for  dynamically  regulating 
admitted  real-time  sessions  in  the  face  of  network  congestion/network  dynamics,  to  take 
advantage  of  the  network  awareness  characteristic  of  RT-DVS  applications. 

•  Middleware  should  be  light  in  terms  of  computation  and  communication  requirements 

•  Middleware  is  designed  to  smartly  trade  the  QoS  of  various  demands  against  each  other. 

•  Translates  application  level  perfonnance  requirements  into  network  perfonnance 
requirements 

•  Identifies  optimization  metrics  for  use  in  resource  allocation 

•  Is  not  dependent  on  routers,  tunnel  end  points,  operating  systems  and  servers  (assumes  no 
proxy  approaches) 

•  Deals  with  links  in  a  path  (tree)  that  has  less/varying  capacities  yet  maintain  performance 
over  lower  capacity  links. 

•  Is  assigned  such  that  changes  in  topology  and  network  conditions,  even  node/link  failures 
should  not  affect  the  operation  of  the  control  mechanism.  Topology  control  problems 
include 

o  Discovering  neighbors 
o  Identifying  position 

o  Determining  transmission  radius  (diameter  of  the  overlay) 
o  Establishing  links  to  neighbors 
o  Maintaining  selected  structure 
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o  Maintaining  infonnation  about  nodes 
o  Information  about  service/node  access  (capacity) 

•  Is  designed  not  to  keep  per  flow  or  aggregate  state  information,  in  order  to  not  have 
complex  signaling  for  per  flow  state  information  as  is  the  case  might  be  with  “stateful” 
QoS  approaches.  Example:  In  stateless  network  model:  real-time,  best  effort  UDP,  TCP 
traffic  per  hop  and  end-to-end  control  algorithms-uses  local  rate  control  for  best  effort 
traffic  and  sender-based  admission  control  for  real-time  UDP. 

4.3  XOMR  Requirement 

Many-to-many  multicast  transmission  is  an  essential  network  capability  for  scalable  distributed 
simulation  because  the  more  common  unicast  approach  does  not  scale  well  with  many-to-many 
traffic.  Also,  providing  reliable  multicast  services  to  RT-DVS  is  an  important  requirement  to 
enable  use  of  web  based  services  across  open  networks  like  the  Internet.  These  services  must 
include  network  level  quality  of  service  (QoS)  for  reliability  and  bounded  latency  as  well  as 
support  for  many-to-many  multicast  communications.  A  number  of  multicast  protocols  have 
been  developed  over  several  years  to  support  group  communications.  Historically,  such 
protocols  have  focused  on  supporting  applications  that  typically  have  one-to-many  type  data 
distributions.  The  obvious  examples  include  streaming  audio  and  video.  Even  these  early 
protocols  have  had  limitations  in  support  of  more  demanding  types  of  applications  (Braudes  and 
Zabele,  1993).  For  RT-DVS  using  web  services,  these  early  protocols  have  proved  to  be 
inadequate  to  support  the  many-to-many  multicast  requirement  as  well  as  their  need  for 
improved  QoS. 

RT-DVS  applications  use  visual  space  management  in  real-time  distributed  simulation  and 
supporting  communications  systems  and  are  evolving  to  web  based  services  and  XML  tagged 
object  characteristics.  The  facilities  and  perfonnance  provided  by  underlying  networks  represent 
an  important  constraint  in  deployment  of  XMSF. 

The  XOMR  overlay  network  requirement  is  presented  in  Figure  6.  The  XOMR  is  an  overlay 
multicast  protocol  designed  to  support  efficient,  reliable  multicast  transmissions  over  existing 
network  protocols  such  as  UDP/IP. 
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Figure  6.  XOM  Overlay 

Widely  deploying  RT-DVS  across  many  organizations  with  large  numbers  of  applications 
requires  robust  multicast  networking  services  that  are  invisible  to  end  users.  The  proposed 
approach  to  XOMR  recognizes  that  underlying  networks  servicing  this  broad  range  of  users 
implies  networking  of  end  users  that  have  a  wide  range  of  network  capacities  and  may  include 
wireless  media  and  low  bandwidths  to  modem  broadband  networks  operating  at  gigabit  speeds. 
The  approach  also  recognizes  that  as  RT-DVS  applications  move  toward  advanced  technologies 
such  as  XML-oriented  Web  services  as  well  as  agent-based  distributed  simulations  (Wang,  et. 
ah,  2003),  there  will  also  be  a  growing  need  for  advanced  networking  services  that  are  not  likely 
to  be  available  in  open  networks  such  as  the  Internet  (Moen  and  Pullen,  2003). 

The  XOMR  solution  must  provide  the  RT-DVS  real-time  response  and  predictable  network 
services  in  order  for  the  end  simulation  systems  to  interact  within  specific  delay  bounds. 
Simulation  users  deployed  across  the  Internet  and/or  Intranets  require  low  latency,  including 
stringent  jitter  requirements  and  high  bandwidth  demands.  Users  also  desire  simplicity  in  the 
sense  that  there  should  be  very  little  configuration  required  to  allow  deployment  and 
establishment  of  service.  The  following  presents  a  summary  of  requirements  for  the  XOMR  in 
four  categories:  Group/overlay  membership  management,  QoS,  Path  management,  and  security. 


60 


4. 3. 1  Group/Overlay  Membership  Management 

•  Need  to  perform  three  basic  functions  in  group  management:  address  management,  service 
registration,  and  group  membership  maintenance. 

•  Registration  services  provide  the  state  of  all  receivers  and  services.  State  information 
includes  number  of  group  members,  membership  updates  as  members  leave  and  join,  the 
availability  of  service,  group  address  and  group  identifier. 

•  Need  to  establish  and  manage  membership  in  a  multicast  group  which  implies  assigning 
multicast  group  addressing  scheme  for  the  overlay.  All  multicast  traffic  is  then  delivered  to 
this  address(s).  This  implies  that  all  members  of  the  group  must  be  listening  for  traffic  with 
this  address.  The  XOMR  allows  for  use  of  either  IGMPv2  (Internet  Group  Management 
Protocol)  or  IGMPv3  locally  to  manage  group  membership.  The  organizational  community 
can  choose  which  to  use,  but  must  be  consistent  across  the  community.  Using  IGMPv3 
allows  implementation  of  source  specific  multicast  where  a  host  joins  specifically  to  a  sender 
and  group  pair.  This  capability  allows  some  level  of  protection  to  the  host  from  receiving 
messages  that  it  did  not  specifically  request  to  receive. 

•  XOMR  doesn’t  provide  an  inherent  address  management  scheme  so  that  an  outside  authority 
(supported  by  the  registry  service  in  XOMR)  is  required  to  provide  the  address  of  the  XOMR 
host.  Inherent  to  XOMR  this  approach  is  a  requirement  for  an  address  assignment  authority 
to  support  local  served  hosts  and  provide  a  service  to  map  multicast  requests  to  an  overlay  IP 
path. 

•  There  should  be  no  explicit  set-up  processing  between  the  sender  and  the  receivers  prior  to 
the  establishment  of  group  communications.  The  XOMR  mechanism  is  required  to  pass  the 
multicast  group  (IP)  address  to  the  XOMR  of  the  associated  receivers.  The  receivers’ 

XOMR  will  have  established  support  for  the  address  prior  to  transmission  in  order  to  receive 
the  data. 

•  To  add  a  new  user  to  an  existing  group,  the  new  receiver  must  first  communicate  directly 
with  the  sender  via  supporting  XOMR  using  a  mechanism  to  join  a  group  and  exchange 
relevant  information  such  as  the  group  address.  The  sender  then  requests  the  XOMR  to  add 
the  new  receiver,  with  the  basic  connection  set-up  processing  invoked  as  before  with  the  new 
connection  completed  only  if  there  is  sufficient  capacity  to  process  the  user. 

•  XOMR  group  membership  can  be  closed  by  either  the  sender  or  the  receiver.  When  the  last 
receiver  along  a  path  has  been  removed,  the  resources  allocated  over  that  path  are  released. 
When  all  receivers  have  been  removed,  the  sender  is  informed  and  has  the  option  of  either 
adding  a  new  receiver  or  tearing  down  the  group. 

•  Connection  set-up  involves  negotiation  of  the  path  capacity  (access  capacity)  and  latency 
parameters  between  the  sender  XOMR,  intennediate  XOMRs,  and  receiver  XOMRs.  If  the 
requested  resources  cannot  be  made  available,  the  sender  is  given  the  option  of  either 
accepting  what  is  available  or  canceling  the  connection  request. 

4.3.2  QoS 

•  Diversity  and  adaptability  must  also  be  accommodated  by  trading  quality  of  service 
(reliability,  latency,  and  possibly  jitter)  with  the  capacity  of  the  access  link.  Multicast 
support  for  quality  trades  can  be  realized  either  through  the  use  of  different  multicast  groups, 
and/or  with  prioritization  of  access  capacity  in  the  overlay.  Reliability  for  multi-class  traffic 
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can  be  accomplished  through  use  of  a  protocol  such  as  SRMP  on  top  of  the  multicast  overlay 
or  queuing  on  the  send  side  based  on  class  of  traffic. 

•  The  XOMR  does  not  provide  a  flow  control  mechanism  in  the  context  that  might  be  used  for 
bulk  data  or  file  transfer.  SRMP  or  equivalent  higher  layer  protocol  is  expected  to  provide  a 
Flow  control  mechanism  to  regulate  the  quantity  of  data  placed  on  the  network  based  on 
feedback  from  the  XOMR  for  these  type  of  applications. 

•  The  XOMR  provides  rate  control  for  access  to  the  underlying  network  service.  The  service  is 
necessary  to  allocate  available  path  resources  and  capacity  in  such  away  that  maintains  the 
minimum  negotiated  QoS  for  the  relay  agent.  Two  classes  of  service  are  supported:  priority 
and  best  effort.  Using  two  classes  provides  a  mechanism  for  application  layer  to  designate 
priority  under  congested  or  constrained  conditions.  The  rate  control  mechanism  also  must 
provide  feedback  to  the  higher  layer  protocol  for  application  layer  flow  control.  The 
objective  is  to  provide  rate  control  from  the  global  network  perspective  based  on  the  costs  of 
network  resources  used  on  a  per  flow  or  group  basis. 

•  The  XOMR  specification  allows  the  user  to  determine  whether  multicast  transfers  are 
unreliable  or  reliable,  where  reliable  transfers  are  defined  to  provide  a  "high-probability  of 
success  of  delivery  to  ah  receivers”.  SRMP  can  provide  the  mechanism  to  manage  this 
capability  and  sends  the  request  to  XOMR.  SRMP,  as  a  transport  protocol,  runs  in  the 
application  host. 

•  The  XOMR,  as  an  overlay,  provides  level  of  guarantees  end-to-end  for  capacity  and  latency. 
The  guarantees  results  from  implementation  of  rate  control  where  the  XOMR  dynamically 
manages  the  path,  ensuring  that  the  available  capacity  is  managed  at  optimum  for  the 
overlay.  The  enforcement  policy  ensures  that  the  same  path  is  followed  for  ah  transmissions 
and  prohibits  new  connections  over  the  network  unless  there  is  sufficient  capacity  to 
accommodate  the  expected  traffic.  This  is  accomplished  by  maintaining  the  statistical  state 
of  ah  connections  in  the  XOMR  relay  host. 

•  The  XOMR  must  acknowledge  and  be  able  to  respond  to  the  introduction  of  priority 
messages  above  already  allocated  capacity.  The  approach  is  implementation  of  a 
conservative  statistical  approach  to  capacity  allocation  where  bursts  of  priority  traffic  will  be 
allowed  within  the  limits  of  the  current  negotiated  QoS  (Simon,  et.  al.,  2003). 

4.3.3  Path  Management 

•  The  XOMR  protocol  suite  requires  routing  support  for  four  functions:  path  set-up,  path  tear- 
down,  packet  forwarding,  and  prioritized  packet  loss  due  to  congestion. 

•  The  routing  tables  must  maintain  both  the  multicast  group  address  and  the  forwarding  path 
on  each  outbound  interface  in  order  to  make  appropriate  routing  decisions. 

•  XOMR  receive  path  set-up  requests  as  required  when  new  members  join  a  multicast  group, 
which  specifies  the  incoming  and  outgoing  interfaces,  the  group  address,  and  the  QOS 
associated  with  the  request.  When  the  message  is  received,  XOMR  establishes  a  path 
between  the  server  and  the  receiver,  and  subsequently  updates  the  multicast  group  state  table. 

Alternatively,  the  service  can  be  aggregated  paths,  and  not  provide  sender  based  trees. 

•  Path  tear-down  requests  also  are  propagated  through  the  XOMRs  when  group  membership 
changes  or  QoS  changes  no  longer  require  data  to  be  sent  over  a  given  route.  These  are  used 
to  inform  XOMRs  of  both  deletions  of  QoS  for  a  given  path  and  deletions  of  entire  paths. 

The  purpose  of  the  message  is  to  explicitly  remove  routing  table  entries  in  order  to  minimize 
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the  time  required  to  stop  forwarding  multicast  data  across  networks  once  the  path  is  no 

longer  required. 

•  Interface  processes  perform  send  and  receive  functions  between  XOMRs  across  the  external 

network  and  with  application  hosts  on  the  attached  subnetworks  (LANS). 

•  The  XOMR  provides  a  connectionless  service — connectionless  implies  sending  messages 
without  permission  hence  buffer  management/overflow  are  required  at  the  receive  side 
application  layer. 

•  The  XOMR  provides  for  two  levels  of  priority  traffic:  Class  0,  no  priority  and  Class  1, 
priority. 

•  Queuing  mechanism  for  sender/receiver  interface. 

•  Local  control  has  to  rely  on  the  existence  of  independent,  end-to-end  algorithms  that  can 
“sense”  and  react  to  the  distributed,  local  actions. 

•  Provide  for  resource  management  by  periodically  gathering  and  updating  infonnation 
about  the  service/network 

4.3.4  XOMR  Security  Requirements 

An  important  question  is  how  much  security  the  XOMR  should  provide.  Is  it  adequate  to 
provide  group  authentication  or  do  need  to  provide  source  authentication?  Group  authentication 
implies  that  the  message  originated  within  the  group  and  has  not  been  modified  by  an  entity 
outside  the  group.  For  sender  authentication,  it  is  implied  that  group  members  would  like  to 
know  for  themselves  the  sender  of  the  message. 

If  we  were  to  apply  a  systems  approach,  then  we  would  like  to  use  concept  of  signatures  to 
detect  and  enable  legitimate  requests,  denying  all  other  traffic.  We  would  like  security  to  be 
built  in,  not  something  added  after  the  fact.  Should  it  be  implemented  in  the  XOMR  server? — 
client  relationship?  How  much  integration?  Can  server  approach  reduce  requirement  for  layered 
and  thereby  increase  performance?  How  do  we  protect  the  ability  of  two  processes  to  exchange 
data  messages  in  the  XOMR  network  protocol? 

•  Authentication — two  processes  exchange  messages  until  each  process  is  certain  that  it  is 
communicating  with  the  other  process 

•  Privacy — each  of  the  processes  uses  its  security  key  to  encrypt  any  data  message  before 
sending  it  to  the  other  process 

•  Integrity — before  sending  a  message,  the  sending  process  uses  its  security  key  to 
compute  an  integrity  check  for  the  message  and  attaches  it  to  the  message.  This  allows 
receiving  process  to  prove  the  message  arrived  without  modification 

•  Non-repudiation — sending  process  computes  digital  signature  to  prove  that  the  message 
is  from  the  sender 

•  Authorization — check  for  authorization  to  use  a  requested  resource/process 

The  minimum  services  available  might  be  to  provide  a  central  authentication  of  senders  via  the 
proposed  registry  services  as  a  “third”  party  provider.  These  services  would  then  allow  for 
membership  access  control  at  the  subnet  level  via  membership  authentication  and  verification  in 
the  context  of  a  specific  multicast  group.  We  also  need  to  consider  protection  of  the  multicast 
distribution  tree;  e.g.  the  routing  protocol  that  manages  and  controls  the  tree. 
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4.4  XOMR  Architecture 

The  architecture  for  the  XOMR  is  presented  in  Figure  7  and  is  purposely  designed  to  be  highly 
modular  so  that  module  optimization  and  alternative  strategies  for  each  module  can  be 
prototyped  for  evaluation.  The  proposed  approach  for  the  XOMR  overlay  is  to  use  UDP  as  the 
underlying  network  protocol  and  offer  services  to  the  application  layer  for  two  different  classes 
of  services:  Class  0-no  priority  and  Class  1 -priority  traffic. 

We  employ  a  priority  queuing  strategy  to  give  priority  to  Class  1  traffic  and  mark  Class  0  traffic 
for  discard  eligible  in  the  event  of  network  congestion.  This  approach  is  consistent  with  our 
previous  efforts  in  development  of  multicast  protocols  such  as  the  Selectively  Reliable  Multicast 
Protocol  (SRMP)  -  see  (Pullen,  1999)  and  (Moen  and  Pullen,  2001). 

Since  this  approach  does  not  provide  error  control,  any  form  of  desired  error  control  must  be 
added  to  the  client  application.  The  design  assumption  is  that  packets  are  relatively  small  (<150 
bytes)  and  the  underlying  network  is  able  to  deliver  packet  guarantees  greater  than  99%  and  has 
reasonable  routing  path  stability  on  the  order  of  minutes.  Reliable  transport  can  also  be  provided 
using  such  protocols  as  SRMP,  shown  in  Figure  9  as  an  example  interface,  where  a  more 
desirable  reliability  is  sought  but  not  available  to  the  client  application.  Alternatively,  the 
application  can  employ  measures  such  as  timeout  and  retransmission  to  handle  discarded 
datagrams  and  sequence  numbers  so  that  clients  can  decide  that  the  datagram  is  old  and  amore 
recent  datagram  is  available  or  a  re-transmission  request  can  be  made. 
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Figure  7.  XOMR  Architecture 


Allocation  of  a  specific  XOMR  IP  address,  or  network  service  access  point,  is  not  considered 
part  of  the  XOMR  protocol  and  requires  the  use  of  an  outside  addressing/registry  authority  to 
establish  an  XOMR  host.  This  provides  a  level  of  security  by  establishing  an  authority  that 
authorizes  a  source  to  be  a  sender  which  can  be  used  by  networked  XOMRs  receivers  for 
recognition  of  authorized  senders  in  the  network.  The  registry  also  will  maintain  the  public 
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routable  IP  address  of  all  active  XOMRs  to  be  used  by  the  XOMRs  to  establish  efficient  overlay 
multicast  paths  between  XOMRs.  The  registry  also  will  maintain  multicast  group  membership 
information.  Once  an  XOMR  host  is  established,  internal  protocol  mechanisms  provide  for  path 
optimization  between  XOMR  hosts  and  manage  multicast  group  membership  at  the  local 
XOMR. 

The  core  of  the  XOMR  is  provided  in  the  Group  and  Path  management  modules  as  the  result  of 
these  activities  provide  the  information  for  the  routing  table  to  be  used  in  making  packet 
forwarding  (routing)  decisions.  A  number  of  approaches  are  being  considered  for  managing  the 
multicast  path  overlay  and  associated  groups: 

•  The  XOMRs  could  provide  a  service  that  is  independent  of  group  management  and 
essentially  provide  a  path(s)  overlay  optimized  across  an  open  network  to  other  registered 
XOMRs.  Under  this  model,  the  path  overlay  looks  like  a  closed  network  with  all  group 
communications  provided  as  single  multicast  network  similar  to  Protocol  Independent 
Multicast  -  Sparse  Mode  (PIM-SM)  specification  (Estrin,  et.  al.  1998).  Each  user  application 
of  the  XOMR,  then  listens  for  desired  group  identification  communications  broadcasted  on 
the  local  area  network  hosting  the  XOMR  and  discards/ignores  unintended  traffic. 

•  The  XOMR  could  provide  a  service  that  recognizes  group  membership  dynamics  (registered 
XOMRs  that  host  users/applications  identified  by  group)  and  provide  an  overly  path 
optimized  for  each  group.  This  approach  generally  is  referred  to  as  source-based  tree 
multicast  (Fei,  et.  al.,  2001). This  implies  management  and  optimization  of  multiple  paths, 
essentially  a  path  structure  for  each  registered  multicast  group.  The  current  XOMR  prototype 
uses  this  approach. 

•  The  XOMR  can  provide  a  service  that  aggregates  group  traffic  across  optimized  paths 
between  XOMRs  as  presented  in  Figure  8.  These  optimized  paths  are  essentially  shared  trees 
and  can  be  optimized  for  capacity  and  delay  to  support  aggregated  group  traffic  (Cui,  et.  al., 
2004).  This  approach  also  is  similar  to  aggregated  group  multicast  over  MPLS  and  with 
added  features  for  group  management. 


Multicast  Groups 


Aggregate  Trees 


Group  Members  Tree  Tree  Links 


g0  XOMRiw,4  -  To  1-4,4-2,4- 


Figure  8.  Group  Aggregation  Overlay 
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In  all  cases,  once  an  XOMR  and  associated  address  is  established,  receivers  will  issue  a  request 
to  join  existing  groups  using  a  unique  connection  identifier  that  is  pre-  assigned  by  the  registry. 
Using  this  approach,  the  RT-DVS  application  is  able  to  control  or  specify  which  sources  of 
information  are  of  interest.  This  is  important  as  we  expect  that  many  disparate  RT-DVS 
applications  could  conceivably  be  using  a  local  supporting  XOMR.  This  helps  protect  an 
individual  RT-DVS  application  from  receipt  of  unspecified  or  undesired  infonnation  flows  and 
also  aids  in  minimizing  overall  network  traffic  load.  This  will  require  that  we  specify  how  the 
XOMR  identifier  is  allocated  and  how  the  receivers  learn  its  value  the  external  registry  service 
and  supporting  protocol. 

At  the  local  level,  the  XOMR  manages  the  receivers’  interests  in  receipt  of  group  messages.  This 
feature  allows  for  a  host  to  report  to  the  local  XOMR  interest  in  receiving  packets  only  from 
specific  source  addresses  and  therefore  aids  in  the  overall  management  of  group  membership  and 
optimization  of  traffic  loads  on  the  network.  This  approach  also  potentially  adds  a  level  of 
security  to  the  RT-DVS  application  as  the  application  is  able  to  discard  or  ignore  messages  from 
unauthorized  sources. 

We  allow  for  the  join  request  from  a  RT-DVS  application  to  specify  whether  the  receiver  wishes 
to  be  a  producer  of  infonnation  as  well  as  a  receiver,  whether  the  connection  should  be  able  to 
provide  the  two  classes  of  service  (no  priority  or  priority),  whether  the  receiver  is  able  to  accept 
multiple  senders  of  information,  the  minimum  throughput  desired,  and  the  maximum  data 
message  size.  This  request  information  is  presented  to  the  supporting  XOMR  and  used  in  the 
group  join  process  to  support  negotiation  of  the  path  capacity  and  latency  parameters  among  the 
sender  XOMR,  intermediate  XOMRs,  and  receiver  XOMRs.  If  the  needed  resources  to  support 
the  request  cannot  be  made  available,  the  sender  is  given  the  option  of  either  accepting  what  is 
available  or  canceling  the  connection  request. 

An  application  request  for  tenninating  membership  in  a  group  is  coordinated  through  the 
supporting  XOMR.  XOMR  connections  can  be  closed  by  either  the  sender  or  the  receiver.  When 
the  last  receiver  along  a  path  has  been  removed,  the  resources  allocated  over  that  path  are 
released.  When  ah  receivers  have  been  removed,  the  sender  is  infonned  and  has  the  option  of 
either  adding  a  new  receiver  or  tearing  down  the  group. 

We  have  not  included  in  the  specification  what  action  the  local  XOMR  should  take  when  the 
application  group  is  reduced  to  a  single  member,  but  a  logical  action  would  be  to  stop 
transmission  if  there  are  no  active  receivers  and  announce  this  to  the  registry  service. 

Our  group  membership  approach  assumes  that  a  group  definition  is  based  on  a  specific 
application  running  behind  an  XOMR  on  the  local  area  network.  Multiple  instances  of  an 
application  are  supported  behind  each  XOMR,  each  of  which  may  have  different  group 
membership  characteristics  to  include  membership  in  multiple  groups.  It  is  also  feasible  for  a 
RT-DVS  application  to  have  membership  in  more  than  one  group.  We  present  an  example  in 
Figure  9.  Notice  that  application  B  has  membership  in  group  1  and  in  group  2.  In  order  to 
maintain  efficiencies  in  packet  transmission,  we  form  a  new  group  3  that  is  the  union  of  the  two 
groups.  We  also  imply  no  explicit  set-up  processing  between  the  sender  and  the  receivers  prior  to 
the  establishment  of  group  communications.  The  XOMR  mechanism  is  required  to  pass  the 
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multicast  group  (IP/group  tag)  address  to  the  XOMR  of  the  associated  receivers.  The  receivers’ 
XOMR  must  have  established  support  for  the  address  prior  to  transmission  in  order  to  receive 
the  data. 


Figure  9.  Group  Membership 


4.5  XOMR  ROUTING  PROTOCOL 
4.5.1  Overview 

The  routing  protocol  defines  the  method  used  by  the  XOMRs  to  exchange  reachability 
information.  Its  key  elements  are  the  use  of  a  central  registry  and  the  local  XOMR  that  provides 
overlay  network  multicast  services  to  supported  RT-DVS  applications.  The  registry  maintains  a 
list  of  all  XOMRs  in  the  network  and  registered  RT-DVS  application  users  with  their  requested 
group  membership,  but  is  not  required  to  maintain  the  topology  of  the  overlay.  The  only 
requirements  are  that  the  registry  responds/replies  to  all  requests  from  an  XOMR  and  any 
XOMR  can  send  messages  at  least  to  their  neighbors  in  the  overlay  network. 

The  XOMR  relies  on  three  steps  to  build  the  overlay.  The  first  step  is  that  a  joining  XOMR  must 
send  a  request  to  the  registry  access  to  the  overlay.  Second,  the  XOMR  must  discover  neighbor 
XOMRs  that  are  potential  candidates  for  the  joining  XOMR  to  establish  a  network  connection 
with,  essentially  building  and  becoming  part  of  an  overlay  mesh.  The  third  step  is  for  the  joining 
XOMR  to  establish  the  services  necessary  for  group  management  and  exchange  this  information 
with  networked  XOMRs,  calculate  (and  update  routing  table)  optimum  paths  (shortest  path  tree) 
for  group  multicast  routing  from  source  to  group  destinations,  and  propagate  that  routing  to  all 
other  XOMRs. 
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There  are  two  mechanisms  that  contribute  to  global  service  guarantees.  The  first  is  that  we  put  a 
limit  on  the  out  degree  of  an  XOMR  using  Bollobas  definition  of  the  degree  of  a  vertex 
(Bollobas,  2001,  p.  60).  That  is,  we  do  not  allow  the  construction  of  more  than  n  connections  to 
other  XOMRs.  This  serves  to  limit  the  processing  demands  and  network  access  capacity  of 
individual  XOMRs  in  the  overlay.  The  second  is  that  we  threshold  the  end-to-end  overall  path 
delay  from  a  sending  XOMR  to  a  destination  XOMR  and  offer  only  best  effort  above  this 
threshold  to  joining  XOMRs  that  do  not  successfully  find  an  existing  XOMR  node  that  is 
adequate  to  maintain  end-end-to-end  path  delay  thresholds;  for  example,  1 10msec  threshold  in 
networking  latency,  based  on  the  fact  that  150  msec  is  representative  of  human  response  times 
for  RT-DVS.  This  can  also  be  accomplished  by  establishing  a  network  diameter  threshold  based 
on  (Bollobas,  2001,  p.  251)  definition  of  network  diameter. 

We  provide  congestion  control  by  providing  two  levels  of  service  to  the  RT-DVS  application. 
Class  0  packets  have  no  priority  and  Class  1  packets  have  priority.  We  apply  weighted  fair 
queuing  giving  priority  to  Class  1  packets  in  the  send  queue  of  the  XOMR  and  discard  Class  0 
packets  randomly  during  congestion. 

Since  the  XOMR  is  hosted  on  the  LAN  that  connects  to  the  supported  RT-DVS  application,  we 
use  IGMPv3  (Cain,  et.  ah,  2002)  for  group  management  at  the  local  level. 

4.5.2  Network  Protocol 

Central  Registry.  A  central  registry  provides  a  service  to  register  the  presence  of  a  XOMR 
and  the  participation  of  an  RT-DVS  application.  The  central  registry  maintains  a  cache  of  all 
nodes  participating  in  the  overlay. 

a.  The  registry  maintains  the  IP  address  of  the  XOMR,  authenticates  and  audits 
continued  participation  in  the  overlay. 

b.  The  central  registry  is  reachable  by  all  XOMR  nodes  at  all  times. 

c.  In  the  request  for  join  by  a  new  XOMR,  the  exchange  messages  will  provide  for 
measurement  of  round  trip  delay  time  (RTT)  between  the  registry  and  the  joining 
XOMR.  The  registry  will  maintain  this  time  and  periodically  update  the 
information. 

d.  On  request  of  a  new  XOMR  to  join  the  network,  the  registry  will  provide  the 
joining  XOMR  the  addresses  of  existing  XOMRs.  The  XOMR  then  randomly 
polls  the  existing  set  of  XOMRs  measuring  the  RTT.  The  responses  with  the 
shortest  RTT  represent  the  initial  best  candidates  as  the  nearest  neighbors  in  the 
overlay.  The  XOMR  continuously  perfonns  random  polling  of  known  member 
XOMRs  of  the  overlay,  always  looking  to  optimize  the  selection  of  best 
neighbors. 

e.  The  registry  provides  for  registration  of  the  RT-DVS  application,  authenticates 
and  authorizes  relationship  to  a  serving  XOMR  as  a  legitimate  source/sender, 
assigns  a  node  ID,  and  maintains  group  membership  participation  based  on  RT- 
DVS  application  request. 

f.  The  registry  group  management  service  provides  for  creation  of  a  multicast  group 
and  assigns  a  group  ID  using  the  IP  multicast  address  as  the  group  ID.  This 
information  is  then  made  available  for  source  and  receiver  RT-DVS  applications. 
A  joining  host  source/receiver  application  can  then  use  the  information  locally  to 


68 


indicate  to  the  XOMR  a  desire  to  join  a  group  by  providing  the  group  ID  to  the 
XOMR  (XOMRs  will  use  IGMP  for  this  function  locally)  (Bhattacharyya,  2003). 

XOMR  Overlay  Construction.  The  XOMR  constructs  an  overlay  using  a  decentralized 
algorithm  by  searching  for  potential  target  existing  network  XOMRs  to  become  the  child  of 
in  the  overlay  (nearest  neighbor).  It  uses  measures  of  RTT  to  candidate  neighbors  to  make 
decisions  on  joining  a  parent  already  in  the  network. 

a.  A  XOMR  wishing  to  join  a  multicast  overlay  sends  a  request  to  the  registry 
indicating  desire  to. 

b.  The  registry  authenticates  the  XOMR  against  a  previously  established 
authorization  in  the  registry  and  responds  to  the  joining  XOMR  with  a  list  of  all 
XOMRs  in  the  existing  network  supporting  the  desired  group  membership. 

c.  The  XOMR  sends  echo  requests  to  N  candidate  XOMR  partners  resulting  in  RTT 
replies. 

d.  If  the  candidate  XOMR  existing  connections  are  less  than  n,  the  parent  XOMR 
responds  with  a  message  indicating  availability  or  else  ignores  the  message. 

e.  The  joining  XOMR  uses  the  message  exchange  to  measure  RTT  to  the 
candidate(s)  partner  XOMR  (s).  With  the  RTT  information,  the  joining  XOMR 
selects  the  best  candidate  as  the  primary  connection  and  selects  the  second  best  as 
an  alternate  path  and  responds  to  these  potential  parents  with  acknowledgement 
of  the  selected  connection  and  ignores  all  other  responses.  The  primary  partner 
and  the  alternate  send  acknowledgements  to  the  joining  XOMR  to  complete  the 
network  join  process. 

f.  The  partner  XOMR  updates  the  routing  table  to  reflect  the  new  neighbors  with 
measured  latency  and  propagates  this  infonnation  to  all  its  neighbors  in  the 
overlay.  The  result  is  a  connected  graph. 

g.  The  XOMR  uses  the  designated  primary  path  unless  it  is  not  available  in  which 
case  it  uses  the  alternate  neighbor  connection. 

h.  The  XOMR  maintains  a  routing  table  which  maps  a  node  ID  to  the  node  IP 
address  and  next  hop,  e.g.  neighbor  along  the  path  to  the  distant  node. 

i.  Periodically,  a  XOMR  sends  heart  beat  probe  messages  to  its  neighbors  to 
determine  if  the  neighbor  is  still  connected  and  if  necessary,  initiates  the  node  join 
process  in  the  case  of  disconnected  nodes  by  sending  a  request  to  the  registry,  or 
by  probing  known  XOMRs  in  the  network. 

j .  Periodically,  each  XOMR  sends  random  discover  messages  to  other  known 
XOMRs  to  discover  if  a  better  neighbor  (link  cost)  is  available  and  makes 
decisions  on  alternate  path  choices  over  using  the  current  path.  To  support  this, 
the  registry  must  periodically  update  the  list  of  known  XOMRs  in  the  overlay. 

Link  Delay  Measurement.  The  XOMR  develops  the  link  delay  data  between  itself  and  its 
neighbors  by  measuring  RTT.  This  infonnation  is  shared  with  the  XOMR  neighbors  and 
propagated  across  the  overlay. 

a.  The  XOMR  collects  link  delay  information  shared  and  periodically  updated  from 
neighbor  XOMR. 

b.  The  link  infonnation  is  propagated  across  the  overlay  so  that  each  XOMR  will 
have  knowledge  of  primary  and  alternate  link  delay  information  between  XOMR 
nodes  in  the  connected  graph.  It  is  not  necessary  to  know  each  link  weight  in  the 
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graph,  if  all  the  nodes  in  the  graph  have  distinct  identities  as  we  imply  by  the 
central  registry.  However,  distributed  minimum  spanning  trees  are  constructed 
with  fewer  messages  if  this  knowledge  exists  at  the  source  node  (Gallager,  et.  al, 
1983). 

Multicast  Tree  construction.  The  overlay  constructed  by  the  distributed  algorithm  is  a 
connected  undirected  graph  with  N  nodes  and  E  edges,  with  a  finite  weight  assigned  to  each 
edge.  A  distributed  algorithm  is  used  at  each  node  to  determine  the  minimum-weight 
spanning  tree  (MST). 

a.  We  desire  the  algorithm  to  optimize  overall  perfonnance  across  the  entire 
overlay.  This  means  optimizing  certain  objective  functions  to  improve  overall 
quality  of  message  delivery.  This  quality  is  typically  measured  in  tenns  of 
latency  and  message  loss.  The  algorithms  solve  a  shortest  path  problem 
potentially  with  many  constraints  to  build  a  tree  connecting  the  source(s)  and 
destination  group  members  so  that  minimal  message  flow  occurs  in  the 
distribution  of  the  message  as  well  as  maintaining  optimum  or  minimum  latency 
form  source  to  each  destination.  The  optimal  case  is  that  only  a  single  copy  of  the 
message  flows  on  any  link  in  the  overlay,  meets  application  latency  requirements, 
and  offers  some  level  of  reliability.  Typical  resources  that  are  allocated  or  that 
must  be  optimized  are  link  capacity,  host  processing  capacity,  number  of  links  or 
diameter  of  the  tree,  and  the  degree  of  a  node  in  the  path  overlay.  In  addition,  the 
algorithm  must  lend  itself  to  supporting  dynamic  overlays  where  many  multicast 
group  members  join  and  leave  in  real-time.  It  is  also  important  to  consider  the 
scalability  of  the  algorithm  which  is  made  considerably  more  difficult  because 
end  systems  typically  have  limited  topological  information  in  which  to  construct 
good  overlay  paths.  All  these  factors  are  considered  in  the  optimization.  A 
number  of  algorithms  are  under  consideration  such  as  the  constrained  Steiner  tree 
(Kompella,  1993)  and  distributed  delay  bond  algorithms  (Jia,  1998).  If  we  run  the 
optimization  algorithm  at  each  node,  we  obtain  aggregate  multicast  paths  from 
each  XOMR  as  a  sender  to  all  other  XOMRs. 

b.  The  addition  of  a  new  node  requires  the  new  node  initially  join  as  a  child  node  as 
described  in  the  XOMR  overlay  construction  procedure  above.  The  join 
information  is  propagated  to  neighbor  nodes  and  the  new  node  runs  the 
distributed  shortest  path  algorithm  and  sends  routing  table  updates  to  the  XOMR 
overlay. 

Node  Departure.  There  are  two  cases  for  node  departure.  A  network  event  may  result  in 
the  XOMR  not  being  available  in  the  overlay,  in  which  case,  the  routing  algorithm  must  be 
able  to  repair  the  overlay  using  the  alternate  link  to  nearest  neighbor.  In  the  second  case,  a 
XOMR  may  no  longer  have  supported  group  members  and  at  some  point  may  desire  to  log 
off  the  overlay.  This  case  represents  a  soft  leave  and  allows  for  message  exchange  to  effect 
new  path  construction  without  the  disruption  of  service. 
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5  EXPERIMENTATION  COMMAND  AND  CONTROL  INTERFACE  (XC2I) 

5.1  Architecture 

Composability  and  web  services  are  both  currently  hot  topics  in  the  M&S  community.  The 
flexibility  and  utility  of  XML  based  web  services  have  the  potential  to  transfonn  existing  and 
future  distributed  simulations,  making  interoperability  a  reality  rather  than  a  theory,  and 
allowing  functionality  to  be  added  selectively  rather  than  monolithically.  In  this  section  we 
focus  on  a  layered  web  services  approach  for  adding  authentication,  access  control,  and  interest 
management  on  top  of  an  existing  HLA  simulation  to  enable  restricted  access  from  a  remote 
location  and  reduce  unwanted  network  traffic.  We  cover  the  technologies  and  techniques 
devised  to  implement  this  proposed  strategy  for  an  exemplar  system,  the  Experimentation 
Command  &  Control  Interface  (XC2I)  project.  Although  this  work  was  not  funded  by  the 
DMSO  XMSF  project  per  se,  it  is  an  excellent  example  of  the  application  of  XMSF  principles 
and  illustrates  the  effect  the  project  is  having  on  development  of  innovative  architectures.  The 
web  services  interest  management  portion  of  XC2I  was  used  by  GMU  to  create  a  credible  HLA 
workload  for  XOM.  The  work  provided  important  insights  into  Web  services  traffic  versus 
simple  tagged  streaming. 

In  the  XC2I,  US  Joint  Forces  Command  (JFCOM)  J9  is  seeking  to  build  on  the  XMSF  DCEE 
(http://www.jfcom.mil/about/fact_dcee.htm)  Viewer  (XDV)  proof  of  principle  to  create  a 
distributed  software  system  that  can  provide  both  two-dimensional  and  three-dimensional 
visualization  of  entities,  aggregates,  and  terrain,  and  scale  up  to  large  federations  of  distributed 
simulations  as  needed  for  Joint  Urban  Operations  (JUO).  In  order  to  realize  these  goals 
advanced  features  such  as  role-based  access  control  (RBAC),  area  of  interest  management 
(AOIM)  (Morse,  et.  ah,  2004b),  and  aggregation  interest  management  (AGIM)  needed  to  be 
developed  and  deployed  alongside  existing  HE  A  simulations,  in  this  case  federated  JSAF 
systems. 

In  this  section  we  describe  the  layered  web  services  architecture  used  to  implement  this 
functionality,  and  the  means  by  which  the  different  features  were  composed  into  a  coherent 
system. 

5.1.1  Overview 

XC2I  has  been  a  collaborative  effort  between  SAIC,  GMU,  and  VMASC  with  funding  from 
JFCOM  J9,  the  eventual  goal  of  which  is  to  develop  a  flexible  2D/3D  viewer/controller  for  C2I 
distributed  simulations.  The  rationale  for  such  a  system  is  one  of  straightforward  economics:  it 
is  often  neither  practical  nor  effective  to  relocate  ranking  officers  to  simulation  centers  in  order 
to  allow  them  to  view  and  interact  with  systems  engaged  in  cooperative  simulation  events.  A 
single,  flexible  C2I  viewer/controller  platform  which  can  remotely  connect  to  these  events  and 
be  transparently  tailored  to  different  systems  would  allow  these  officers  to  view  and  interact  with 
the  simulations  without  the  cost  in  time  and  money  associated  with  relocation. 

Toward  this  end,  the  teammates  designed  an  architecture  for  such  a  system  and  began 
implementation  of  a  prototype  for  use  with  an  existing  simulation  involving  distributed  JSAF 
instances  modeling  JUO  scenarios.  While  this  prototype  will  be  used  as  an  exemplar  throughout 
the  rest  of  this  section,  it  is  important  to  note  that  it  was  simply  a  proof  of  concept 
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implementation  tailored  to  a  specific  application,  and  therefore  some  of  the  functionality  and 
capabilities  designed  into  the  architecture  do  not  apply  directly,  and  in  fact  have  in  some  cases 
yet  to  be  implemented. 


The  prototype  implementation  was  designed  to  interact  with  an  HLA-compliant  simulation  of 
distributed  JSAF  instances  customized  for  JUO  scenarios  and  was  interconnected  using  RTI-s. 
This  meant  that  actual  implementations  were  needed  for  the  access  control  subsystem,  AOIM, 
AGIM,  and  an  HLA  data  feed  connector  built  for  RTI-s.  An  additional  data  feed  connector  was 
also  required  to  connect  directly  to  the  JSAF  Persistent  Object  Store  (POS)  as  not  all  required 
data  could  be  retrieved  directly  via  RTI-s.  Finally,  a  C2IML-aware  control  system  needed  to  be 
added,  with  another  connection  directly  to  the  POS,  to  allow  orders  to  be  passed  from  the  XC2I 
client  to  entities  controlled  directly  by  JSAF.  The  visualization  component  chosen  for  the  front- 
end  was  a  modified  SOFVIZ  3D  viewer,  itself  a  customization  of  OpenSceneGraph  for  the 
Windows  platform.  Figure  10  shows  an  overview  of  the  architecture. 


XC2I 


Figure  10.  Experimentation  Command  and  Control  Interface  Concept 

As  the  figure  illustrates,  a  common  visualization  front-end  would  be  presented  to  the  user,  while 
simulation  specific  data  feeds  and  control  modules  would  be  incorporated  dynamically 
depending  on  the  simulation  to  which  the  viewer  is  being  connected. 

In  order  to  maintain  this  level  of  modularity,  two  XML-based  languages  were  developed. 
C2IML  links  the  semantics  encapsulated  by  the  C2IEDM  specification  with  XML  syntax, 
providing  a  well-defined  vocabulary  for  defining  AOIM  and  AGIM.  An  Access  Control 
Language  (ACL)  was  then  developed  for  the  RBAC  system.  As  these  languages  define  the 
interfaces  between  the  client  system  and  the  simulations  being  viewed  or  controlled,  the  XC2I 
client  system  can  be  transparently  customized  for  different  back-end  simulations  given  the 
connection  endpoint  of  the  C2IML  and  ACL  aware  service  endpoints.  This  is  important  as 
different  simulations  will  need  different  levels  of  AOIM,  AGIM,  and  security  requirements,  yet 
they  must  all  understand  the  same  interest  and  access  control  expressions  if  XC2I  is  to  be 
effective. 
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5.1.2  RBAC  Architecture 


The  chief  goals  in  defining  the  architecture  for  the  authentication  and  authorization  subsystem 
for  XC2I  were: 

•  Defining  a  globally  available  identity  management  system. 

•  Associating  user  identities  with  simulation-specific  roles. 

•  Transparently  limiting  user  interaction  with  the  client  based  upon  the  user’s  available  roles. 

As  an  example,  a  user  who  is  authorized  to  only  view  and  control  blue  forces  should  not  be 
presented  with  related  options  reserved  for  the  red  or  white  forces.  The  sequence  diagrams  below 
show  how  these  goals  are  met  by  the  architecture. 

Figure  1 1  illustrates  the  process  by  which  a  user  is  authenticated  by  the  access  control  system. 
The  user  begins  by  entering  a  username  and  password  at  the  client  login  prompt.  This 
information  is  used  to  access  a  globally  unique  signed  certificate  that  the  user  must  implicitly 
present  to  the  system,  either  via  a  secure  keystore  on  disk  or  a  physical  token  like  a  smartcard.  It 
is  this  certificate  that  is  sent  to  the  access  control  server  and  used  for  identification  services.  As 
these  certificates  are  already  provided  to  many  DoD  personnel  as  physical  tokens  and  similar 
authentication  systems,  and  the  certificate  authority  infrastructure  is  already  in  place  for  the 
DoD,  the  validity  of  the  certificate  can  be  checked  by  ensuring  that  an  accepted  authority  signed 
it.  The  identification  information  found  within  the  certificate  can  then  be  used  to  look  up  the  user 
privileges  on  the  access  control  server  for  the  requested  system  or  simulation.  While  currently 
this  lookup  is  done  using  a  relational  database,  other,  more  distributed  identity  management 
systems  can  be  used  (e.g.,  LDAP).  Once  the  user  has  been  authenticated  and  the  available  roles 
determined,  the  access  control  server  returns  a  list  of  roles  to  the  client,  where  each  role  is 
associated  with  an  encrypted,  signed  token. 
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Figure  11.  Authorization  Sequence  Diagram 

Once  the  list  of  available  roles  is  received,  the  client  offers  the  user  an  opportunity  to  select  the 
preferred  role  as  illustrated  in  Figure  12.  When  the  user  selects  a  role,  the  client  connects  to  the 
simulation  via  a  top  level  Web  Services  Interest  Management  (WSIM)  server,  requesting  that  a 
session  be  started  for  the  user  with  the  given  role.  The  request  includes  the  token  received  earlier 
from  the  access  control  server.  The  WSIM  server  then  verities  the  authenticity  of  the  token  by 
verifying  the  validity  of  the  signature  over  the  token  using  the  access  control  server's  public  key. 
If  the  access  control  server's  key  is  not  known  the  WSIM  server  needs  to  contact  the  access 
control  server  directly  to  retrieve  it  for  verification.  The  token  is  then  sent  on  to  the  access 
control  server  to  be  unencrypted  and  verified.  If  the  token  is  valid,  the  WSIM  server  caches  the 
role  information  in  the  session  information  associated  with  the  requesting  client  and  connects  to 
the  simulation.  Although  these  sequence  diagrams  do  not  illustrate  the  processes  for  responding 
to  exceptions,  the  traditional  exceptions  that  can  be  thrown  by  an  authentication  system  can  be 
incorporated. 
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Figure  12.  Interest  Management  Access  Control  Initialization  Sequence  Diagram 


5.1.3  Components 
ACL 

The  following  subsections  demonstrate  example  XML  exchanges  illustrated  in  the  previous 
sequence  diagrams.  The  first  is  the  login  with  the  username  and  certificate  in  Figure  11.  The 
details  of  the  type  of  authentication,  in  this  example  a  user’s  login,  are  hidden  in  the  token 
passed  for  authentication.  This  is  followed  by  the  access  control  server’s  response  in  the  same 
figure.  The  third  example  details  the  role  request  with  the  user’s  token  between  the  viewer 
access  control  and  the  WSIM  server  as  illustrated  in  Figure  12. 

Initial  Client  Request 

1  <?xml  version= " 1 . 0 " ?> 

2  <SOAP : Envelope 

3  xmlns : SOAP= "http : //www . w3 . org/2  003 /05/ soap -envelope" 

4  xmlns  :  ds=  "http  :  /  /www .  w3  .  org/2  000/ 09/xmldsig# " 

5  xmlns  :  xenc=  "http  :  /  /www .  w3  .  org/2  001/ 04/xmlenc#  " 

6  xmlns : wsse= "http : //docs . oasis -open . org/wss/2004/  01/oasis-200401- 

wsswssecurity-secext-1 . 0 .xsd" 

7  xmlns : wsu= " http : / /docs . oasis -open. org/wss/2004/ 01/  oasis-200401- 

wssws security- utility-1.0. xsd" 
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8  xmlns : acl= "http : / /www . xmsf . com/xc2i /access -control " > 

9  <SOAP : Header> 

10  <wsse : Security^ 

11  <wsse : BinarySecurityToken 

12  ValueType= " . . . #X509v3" 

13  EncodingType= "http : //www . w3 . org/2000/09/  xmldsig#base64Binary " 

14  wsu : Id= "auth509Token" > 

15  TdaRFggQeLVoa . . . 

16  </wsse : BinarySecurityToken> 

17  </wsse : Security> 

18  </S0AP : Header > 

19  <SOAP:Body> 

20  <acl : AuthorizationRequest> 

21  <acl : RequestedServices> 

22  <acl : RequestedService  URI= "xc2i : // j 9 . mil/ juo- j saf " /> 

23  </acl : RequestedServices> 

24  </acl :AuthorizationRequest> 

25  </SOAP:Body> 

26  </ SOAP : Envelope > 

Before  describing  the  individual  elements  of  the  message  above,  it  is  worth  clarifying  a  few 
details  regarding  the  structure  of  the  message  itself.  First,  the  ACL-specific  tags  are  contained 
within  the  body  of  a  SOAP  message,  thereby  making  the  request  itself  syntactically  compliant 
with  current  web  services  standards.  Second,  a  number  of  different  namespaces  are  utilized  in 
this  and  the  following  examples.  This  is  due  to  the  fact  that  the  existing  web  services  security 
specification  builds  on  a  number  of  other  technologies.  Line  4  references  the  W3C  XML  Digital 
Signature  specification,  line  5  the  W3C  XML  Encryption  specification,  line  6  the  OASIS  Web 
Services  Security  specification,  and  line  7  the  access  control  language  developed  for  this  project. 
The  abbreviations  used  to  reference  these  namespaces  are  consistent  throughout  the  examples. 
Please  also  note  that  while  a  number  of  encryption  and  digital  signing  techniques  have  been 
integrated  into  the  language,  there  was  an  implicit  design  assumption  that  these  messages  would 
be  transferred  over  a  secure,  encrypted  protocol  (e.g.,  HTTPS  using  SSLv3  or  TLS). 

The  request  message  itself  is  quite  straightforward.  Lines  10-17  denote  a  Web  Services  Security 
block  containing  the  client's  certificate  on  lines  11-16.  Lines  20-24  make  up  the  actual 
authorization  request.  Within  this  request,  lines  21-23  list  the  services  for  which  the  client  is 
requesting  access,  in  this  case  an  XC2I  connection  to  the  JUO  version  of  JSAF. 

Access  Control  Server  Response 

1  <?xml  version= " 1 . 0 " ?> 

2  <SOAP : Envelope 

3  xmlns : SOAP= "http : //www . w3 . org/2  003 /05/ soap -envelope" 

4  xmlns  :  ds=  "http  :  /  /www .  w3  .  org/2 000/ 09/xmldsig# " 

5  xmlns : xenc= "http : //www . w3 . org/2  001/ 04/xmlenc# " 

6  xmlns : wsse= "http : //docs . oasis -open . org/wss/2  0  04/ 01/  oasis-2  00401- 

wsswssecurity-secext-1 . 0 . xsd" 

7  xmlns : wsu= "http : //docs . oasis -open . org/ ws s/ 2004/ 01/ oasis-200401 - 

wsswssecurity-utility-1 . 0 .xsd" 

8  xmlns : acl= "http : // www . xmsf . com/xc2i /access -control " > 

9  <SOAP : Header> 

10  <wsse : Security> 

11  <wsu : Timestamp  wsu : Id= " tstamp" > 

12  <wsu : Created>2  0  04  -  0  5 -2 IT 0  8 : 42 : 0OZ</wsu : Created> 

13  </wsu : Timestamp> 

14  <xenc : EncryptedKey> 

15  <xenc : EncryptionMethod  Algorithm=  "http : //www . w3 . org/2001 /04/xmlenc#rsa- 

1_5 "/> 

16  <ds:KeyInfo> 

17  <wsse : SecurityTokenRef erence> 

18  <wsse : Ref erence 

URI= "http : / / www . certRepository/  X509Certs/theClientCert"/> 
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< /wsse : SecurityTokenRef erence> 

</ds : KeyInfo> 

<xenc : CipherData> 

<xenc : CipherValue>asdsdkj hhj 278yasdf . . .  </xenc : CipherValue> 

</xenc : CipherData> 

< / xenc : EncryptedKey > 

<ds : Signature> 

<ds : SignedInfo> 

<ds : CanonicalizationMethod  Algorithm= "http : / /www.w3 . org/2001/10/xml- 
exc-cl4n# " /> 

<ds : SignatureMethod  Algor ithm= "http : //www . w3 . org/2 00  0/ 09/xmldsig#rsa- 
shal " /> 

<ds : Ref erence  URI="#body"> 

<ds : DigestMethod 

Algor ithm= "http : // www . w3 . org/2  000/ 0  9/xmldsig#shal " / > 

<ds : DigestValue>KLSDF72365FDA . . . </ds : DigestValue> 

</ds : Reference> 

</ds : SignedInfo> 

<ds : SignatureValue>Adf ab234asd . . . </ds : SignatureValue> 

<ds : Keylnf o> 

<wsse : SecurityTokenRef erence> 

<wsse : Reference 

URI="http : / /www. certRepository/X509Certs/authServerCert"/ > 
</wsse : SecurityTokenRef erence> 

</ds : KeyInfo> 

</ds : Signature> 

</wsse : Security> 

</S0AP : Header > 

<SOAP:Body  wsu : Id= "body" > 

<acl : Author izationResponse> 

<acl : Services> 

<acl : Service  URI  =  "xc2i : // j  9 . mil/ juo- j  saf " > 

<acl:Role  id="White"> 

<acl : Token> 

<enc : EncryptedData  Type= "http : // www . w3 . org/2 001/ 04/xmlenc#Content " 
xmlns : enc= "http : //www . w3 . org/2  0  01/ 04/xmlenc# " > 

<enc : encryptionMethod 

Algor ithm= "http : // www . w3 . org/2  0  01/ 04/  xmlenc#aesl28-cbc> 

<!-- Implicitly  use  symmetric  key  encrypted  above. --> 

<enc : CipherData> 

<enc : CipherValue>  AB342311CE93 . . . </enc : CipherValue> 

</enc : CipherData> 

</enc : EncryptedData> 

</acl : Token> 

</acl : Role> 

</acl : Service> 

</acl : Service s> 

</acl : Author iz at ionResponse> 

</S0AP : Body> 

</S0AP : Envelope> 


This  is  the  response  to  the  previous  query.  Lines  14-24  contain  an  encrypted  symmetric  key  used 
to  encrypt  the  security  tokens  found  later.  This  symmetric  key  is  encrypted  using  the  client's 
public  key,  which  was  extracted  from  the  certificate  provided  with  the  request.  Lines  25-40 
contain  a  digital  signature  across  the  body  of  the  message.  The  message  is  signed  using  the 
authenticating  server's  private  key.  Lines  35-39  reference  the  server's  certificate,  allowing  a 
receiving  client  to  verify  the  signature.  Line  47  lists  the  role  for  which  a  token  follows.  Finally, 
lines  48-58  contain  the  actual  encrypted  token. 


Example  Unencrypted  Token 

1  <! --Here's  the  structure  of  the  Token  element 

2  which  is  extracted  from  the  EncryptedData  element.  --> 

3  <acl : Token 

4  xmlns  :  ds=  "http  :  /  /www .  w3  .  org/2  000/ 09/xmldsig#  " 

5  xmlns : xenc= "http : //www . w3 . org/2  001/ 04/xmlenc# " 
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xmlns : wsse= "http : //docs . oasis -open . org/wss/2004/ 01/ 

oasis-200401-wsswssecurity-secext-l . 0 .xsd" 
xmlns : wsu= "http : / /docs . oasis -open . org/wss/2004/ 01/ 

oasis-200401-wsswssecurity-utility-l . 0 .xsd" 
xmlns : acl= "http : / /www . xmsf . com/xc2i /access -control " > 

<acl : TokenHeader> 

<wsse : Security> 

<wsu : Timestamp  wsu : Id= " toklTstamp" > 

<wsu : Created>2004 -05-21T08:42: 00Z</wsu : Created> 

</wsu : Timestamp> 

<wsse : BinarySecurityToken 
ValueType= " . . ,#X509v3" 

EncodingType= 

"http : / /www . w3 . org/2000/09/xmldsig#base64Binary" 
wsu : Id= "auth509Token" > 

KMHASDFKHasdf 234 j  ha .  .  . 

< /wsse : BinarySecurityToken> 

<!- -Signature  for  Body--> 

<ds : Signature> 

<ds : Signedlnf o> 

<ds : CanonicalizationMethod  Algorithm= 

"http : / /www . w3 . org/2  0  01/10/xml -exc-cl4n# " /> 

<ds : SignatureMethod  Algorithm= 

"http : / /www . w3 . org/2  000/ 09/xmldsig#rsa- shal " / > 
<ds : Ref erence  URI= " #toklBody" > 

<ds : DigestMethod  Algorithm= 

"http : / /www . w3 . org/2  0  0  0/ 0  9/xmldsig#shal " / > 

<ds :DigestValue>KLSDF72365FDA. . . </ds : DigestValue> 

</ds : Ref erence > 

</ds : SignedInfo> 

<ds : SignatureValue>Adf ab234asd . . . </ds : SignatureValue> 

<ds : Keylnf o> 

<wsse : SecurityTokenRef erence> 

<wsse : Reference  URI= " #auth509Token" / > 

</wsse : SecurityTokenRef erence> 

</ds : Keylnf o> 

</ds : Signature> 

</wsse : Security> 

</acl : TokenHeader > 

<acl : TokenBody  wsu : Id= " toklBody " > 

<! --Client  Username- -> 

<wsse : UsernameToken> 

<wsse :Username>Me</wsse :Username> 

</wsse : UsernameToken> 

<!- -Certificate  for  client--> 

<wsse : BinarySecurityToken 
ValueType= " . . ,#X509v3" 

EncodingType= 

"http  :  / /www .  w3  .  org/2 0 0 0/ 0 9/xml dsig#base 6 4 Binary" 
wsu : Id= " client 50 9Token" > 

KMHASDFKHasdf 234 j ha. . . 

</wsse : BinarySecurityToken> 

<!- -Unique  identifier  for  the  service  --> 

<acl : ServiceURI>xc2i : // j  9 . mil/ juo- j  saf </acl : ServiceURI> 

< ! - -Role- - > 

<acl : Role>White</ acl : Role> 

</acl : TokenBody> 

</acl : Token> 


This  is  what  the  token  looks  like  unencrypted.  Note  that  lines  14-19  contain  the  authentication 
server's  certificate  and  lines  45-50  contain  the  client’s  certificate.  This  allows  the  service  to 
verify  the  identity  of  both  the  signing  authority  and  the  connecting  client.  The  token  itself 
contains  the  client's  username  on  lines  41-43,  the  aforementioned  client  certificate,  the  service  to 
which  it  applies  on  line  52,  and  the  authenticated  role  on  line  54. 


WSIM 

The  need  for  a  comprehensive  approach  to  WSIM  became  apparent  in  the  early  design  stages  for 
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XC2I.  In  large  scale  simulations  like  JUO/JSAF,  updates  are  potentially  being  sent  by 
thousands,  or  even  hundreds  of  thousands  of  entities  spread  throughout  the  battlespace.  These 
updates  generate  more  traffic  than  can  be  accommodated  by  all  but  the  highest  bandwidth 
connections,  making  it  difficult  or  impossible  to  forward  all  data  over  a  wide  area  network.  The 
JUO/JSAF  federation  deals  with  this  traffic  glut  through  creative  use  of  HLA  Data  Distribution 
Management  (DDM)  and  by  traffic  shaping  via  the  RTI-s  simply  to  manage  throughput  on  a 
LAN.  This  solution  was  untenable  for  XC2I  for  several  reasons.  First,  the  XC2I  architecture 
was  meant  to  provide  an  abstract  interface  to  C2I  simulation  systems  regardless  of  their 
underlying  implementations.  Second,  because  there  is  not  standard  practice  for  implementing  an 
HLA  DDM  scheme  across  simulations,  we  could  not  count  on  the  existence  of  applicable  region 
information.  Finally,  the  XC2I  solution  needed  to  be  adaptable  to  non-HLA  data  sources, 
meaning  that  any  solution  that  could  not  be  applied  to  DIS  and  other  simulation  interoperability 
protocols  was  unacceptable. 

Based  on  the  unique  needs  of  the  C2I  viewer  space,  it  was  decided  that  two  separate  levels  of 
interest  management  would  be  required.  The  first,  AOIM,  would  focus  on  limiting  subscription 
to  the  geographically  relevant  subset  of  specific  entities  and  types,  and  further  filtering  on 
visible,  or  otherwise  relevant  movement  and  update  rates.  The  second,  AGIM,  would  focus  on 
aggregated  data,  an  example  of  which  is  representing  a  number  of  units  as  a  single  coherent 
battle  grouping  such  as  a  brigade  or  battalion.  C2IML  was  developed  to  encapsulate  these  IM 
schemes.  Developed  as  an  interpretation  of  the  C2IEDM  specification  in  XML,  C2IML  provides 
the  syntax  for  describing  subscription  in  terms  of  Interest  Expressions  (IE)  that  detail  the  XC2I 
user's  AOI  and  AGI. 

AOIM 

AOIM  is  based  primarily  upon  geographic  location,  object  type,  and  object  id.  However, 

C2IML  has  been  designed  with  facilities  to  allow  further  filtering  of  AOI  based  upon  update 
frequency  and  geographical  deltas. 

In  the  viewer  currently  under  development,  the  user  subscribes  to  types  of  entities  in  a 
geographic  region  using  a  GUI.  We  define  this  geographic  region  as  the  subscribing  viewbox. 
For  simplicity,  all  IEs  have  at  most  one  viewbox.  All  other  operands  are  interpreted  to  be 
subscriptions  within  the  viewbox.  The  current  language  assumes  that  IEs  are  additive,  i.e.  that 
each  subscription  for  a  given  viewbox  adds  to  any  previous  subscriptions  for  the  same  viewbox. 
The  following  restrictions  are  enforced  for  the  limited  scope  of  the  current  viewer: 

•  A  user  can  only  subscribe  to  entities  in  the  current  viewbox. 

•  If  an  entity  of  interest  moves  out  of  the  viewbox  (“out  of  scope”),  its  updates  won’t  be 
delivered  again  until  it’s  back  in  scope,  but  the  subscription  will  remain  in  effect.  This  is 
enforced  by  the  viewer,  not  by  C2IML. 

The  rationale  behind  filtering  AOI  via  geographical  deltas  was  simple:  within  the  context  of  the 
viewer,  any  movement  too  subtle  to  be  seen  at  the  user's  current  zoom  level  wasted  bandwidth  if 
sent.  Similarly,  update  frequency  could  be  used  to  filter  out  data  updated  more  frequently  than 
the  screen  could  be  refreshed,  or  alternately  could  be  used  to  arbitrarily  throttle  back  updates  to  a 
level  supported  by  the  available  bandwidth.  While  a  user  would  choose  their  viewbox  and  any 
specific  entities  and  types  to  which  they  wished  to  subscribe,  geographical  deltas  and  update 
frequency  parameters  would  likely  only  ever  be  used  transparently  by  the  XC2I  system  itself. 

The  example  below  is  a  C2IML  IE  illustrating  many  of  these  principles. 
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1  <c2iml : InterestExpression  xmlns :xsi= "http : // www . w3 . org/2 001/XMLSchema- instance " 

2  xsi : schemaLocation= "file://./c2iml.xsd" 

3  xmlns : c2iml= "http : / /www . xmsf . com/xc2i/c2iml " > 

4  <c2iml : Viewbox> 

5  <c2iml : CornerPosition  lat="30.720"  lon= " - 98 . 588 " /> 

6  <c2iml : CornerPosition  lat="31.720"  lon= " - 97 . 588 " /> 

7  <c2iml : BoxHeight  baseAltitude= " 0 "  height= " 9000 " /> 

8  </c2iml :Viewbox> 

9  <c2iml : GeodeltaFilter  distance= " 1000 " /> 

10  <c2iml : TemporalFilter> 

11  <c2iml : Time>3 00</c2iml : Time> 

12  <c2iml :Update>10</c2iml :Update> 

13  </c2iml : TemporalFilter> 

14  <c2iml : Ob j ectTypeList > 

15  <c2iml : Ob j ectType  id="l"/> 

16  <c2iml : Ob j ectType  id="2"/> 

17  <c2iml : Ob j ectType  id="4"/> 

18  </c2iml : Ob j ectTypeList> 

19  <c2iml : Ob j ectltemList > 

20  <c2iml : Ob j ectltem  id="356"/> 

21  </c2iml : Ob j ectItemList> 

22  </c2iml : InterestExpression> 

This  example  bears  some  explanation.  Lines  4-8  define  a  geographical  Viewbox  giving  the 
upper  left  and  lower  right  corners  in  terms  of  their  latitude  and  longitude  (5-6),  the  base  height  of 
the  bottom  of  the  bounding  box,  and  the  height  of  the  box(7).  This  information  is  sufficient  to 
define  a  geographically  unique  volume  in  space.  Note  that  the  BoxHeight  element  is  optional.  If 
not  included  it  is  assumed  that  the  area  of  interest  includes  all  heights  above  and  below  sea  level 
within  the  rectangle  defined  by  the  two  bounding  corners. 

Following  the  Viewbox  is  a  series  of  general  ObjectType  entries  (14-18).  The  ObjectType 
element  is  defined  on  lines  37-44  of  the  Schema.  This  describes  an  interest  in  particular  classes 
of  entities.  After  the  class  interest  statement  is  a  separate  list  of  individual  entities  of 
interest(19). 

The  GeodeltaFilter  on  line  9  defines  a  minimum  geographical  granularity  filter,  asking  that 
updates  that  involve  a  delta  less  than  this  distance  not  be  sent.  This  filter  would  be  used  to  limit 
traffic  to  a  viewer  to  changes  which  could  be  seen  at  the  current  zoom  resolution.  A 
TemporalFilter  is  used  on  lines  10-13.  The  TemporalFilter  sets  a  filter  on  the  rate  at  which 
updates  are  to  be  passed  to  the  client.  In  this  case,  line  1 1  asks  that  updates  be  filtered  if  they  are 
received  more  than  once  every  300  milliseconds,  and  line  12  asks  for  only  every  tenth  update. 
AGIM 

AGIM  is  a  new  concept  developed  for  this  viewer  allowing  a  user  to  see  aggregated  views  of 
individual  entities.  This  concept  is  most  applicable  to  force-on-force  simulations.  AGIM  has 
some  unique  challenges,  including  deriving  the  unit  order  of  battle  when  it  is  not  explicitly 
provided  and  determining  the  location  at  which  to  display  the  aggregated  entity.  It  also  has  some 
clear  advantages  in  the  C2I  space,  especially  when  dealing  with  large  force-on-force  simulations. 
If  a  user  is  only  interested  in  seeing  and  interacting  with  an  aggregate,  updates  need  only  be  sent 
to  the  XC2I  client  for  the  entire  aggregate.  By  placing  this  functionality  into  the  WSIM 
architecture  bandwidth  is  drastically  reduced  and  processing  is  offloaded  from  the  client  to  the 
machines  hosting  the  web  services,  which  could  be  clustered  or  load-balanced.  AGIM  support  is 
application  specific  and  is  expressed  in  C2IML  using  ObjectType  and  Objectltem  elements.  The 
actual  aggregation  of  individual  entities  must  be  either  supported  by  the  underlying  simulation  or 
the  layered  web  services  acting  as  intennediaries. 


Future  Work 
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While  the  ACL  and  architecture  have  been  prototyped,  shortcomings  of  the  Web  Services 
standards  and  work  being  done  by  the  OASIS  standards  body  indicate  that  the  current  work  may 
be  superseded  by  a  significantly  different  message  format,  such  as  the  extensible  Access  Control 
Meta  Language  (XACML).  However,  the  fundamental  architecture  presented  in  this  document 
will  continue  to  be  appropriate  to  the  application.  Additionally,  the  WSIM  implementation 
currently  has  only  preliminary  support  for  an  HLA  1.3  data  feed.  Extending  the  scope  to  include 
interchangeable  HLA  1.3,  1516,  and  DIS  feeds  would  help  prove  the  viability  of  the  architecture. 
Finally,  exchanging  the  current  GUI  front-end  for  a  cross-platform  browser-launchable 
interface,  perhaps  written  in  Java,  would  greatly  increase  the  flexibility  of  the  XC2I  application. 
While  the  WSIM  in  particular  was  accepted  in  the  broader  M&S  and  IT  community  and  resulted 
in  several  referenced  publications  of  the  XMSF  group,  the  J9/JFCOM-sponsored  project  was 
tenninated  in  early  Spring  2004  due  to  redirection  of  funds  in  support  of  the  war  in  Iraq. 

5.3  Conclusions 

The  current  paradigm  of  co-locating  participants  in  distributed  simulation  events  has  become 
outdated  and  costly.  Current  methods  for  allowing  truly  distributed  participation  require 
extensive  configuration  and  end-to-end  control  of  the  networks  involved.  If  simulation 
participation  is  to  be  truly  distributed  and  flexible,  remote  users  must  be  able  to  easily  configure 
and  run  clients  without  extensive  knowledge  of  the  underlying  systems  while  maintaining  both 
security  and  performance.  We  believe  that  the  layered  web  services  approach  taken  by  XC2I  is  a 
positive  step  in  this  direction.  Moreover,  replacing  proprietary  solutions  with  open  standards 
solutions,  in  particular  for  the  visualization  components,  is  mandatory  in  the  context  of  XMSF. 
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Management  Language  Initiatives  for  NATO  Projects,”  Paper  12,  Proceedings  RT A/MSG 
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Katherine  L.  Morse,  Andreas  Tolk,  J.  Mark  Pullen,  Don  Brutzman:  “XMSF  as  an  Enabler  for 
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Dennis  Moen,  J.  Mark  Pullen,  and  Fei  Zhao,  "Implementation  of  Host-based  Overlay  Multicast 
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•  Mark  Pullen:  "WSIM  Prototype" 
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Tutorial  during  the  I/ITSEC  2004 


86 


Sue  Numrich,  Mike  Hieb,  Andreas  Tolk:  "M&S  in  the  GIG  Environment' 


6.3  Workshops 

Presentations  at  the  2004  Web3D  Conference,  Monterey,  CA,  April  2004: 

•  Don  Brutzman:  “Extensible  Modeling  and  Simulation  Framework  (XMSF)  Overview” 
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•  Don  Brutzman:  "Extensible  Interoperability  Framework  (X3D  and  XMSF)" 

•  Andreas  Tolk:  "Web-based  Modeling  and  Simulation  and  the  SISO" 

•  Don  Brutzman:  "Web-based  Modeling  and  Simulation  and  the  Web3D  Consortium" 

•  Andreas  Tolk:  "Metamodels  and  Mappings  —  Ending  the  Interoperability  War" 

•  Katherine  Morse:  "Layered  Web  Services  for  M&S" 

•  Charles  Tumitsa:  "Lessons  Learned  on  a  Service-Oriented  Architecture  Employed  in 
Implementing  a  Web  Enabled  C2I  Visualization  Tool  for  Joint  Forces  Command  (JFCOM)” 

6.4  Other  Activities 

Presentations  at  the  2004  MOVES  Open  House,  Naval  Postgraduate  School,  Monterey,  CA, 
August  2004: 

•  Curtis  Blais:  "Semantic  Web  Technologies  for  Military  M&S" 

•  Don  Brutzman,  Mark  Pullen,  Andreas  Tolk,  Katherine  Morse:  "Extensible  Modeling  and 
Simulation  Framework  (XMSF)  Project  Update" 

•  Don  Brutzman,  Mark  Pullen,  Andreas  Tolk:  "Quick-look  Report  on  the  XMSF  Developers' 
Deep-Dive  Workshop" 

•  Katherine  Morse:  "XMSF  Profiles" 

•  Maj  Glenn  Hodges:  "Designing  a  Common  Interchange  Fonnat  for  Unit  Data  using  C2IEDM 
and  XSLT" 

•  LT  Scott  Rosetti:  "XMSF  Exemplar  Projects:  Sonar  Visualization" 

•  Don  McGregor,  LT  Matt  Mackay,  Don  Brutzman:  "XMSF  Exemplar  Projects:  XML-based 
Tactical  Chat  (XTC)" 

•  CDR  Duane  Davis:  "XMSF  Exemplar  Projects:  Autonomous  Underwater  Vehicle  (AUV) 
Workbench" 

•  LT  Terry  Norbraten:  "XMSF  Exemplar  Projects:  XML  Schema-based  Binary  Compression 
(XSBC)" 

•  Andreas  Tolk:  "XC2I  Overview  and  Viewer/Controller  Technology" 

•  Katherine  Morse:  "XC2I  Web  Service  Interest  Management" 

•  Mark  Pullen:  "XC2I  Application  of  XMSF  Overlay  Multicast" 

Presentations  during  the  NATO  M&S  Conference  on  “M&S  to  address  NATO’s  new  and 
existing  Military  Requirements”,  held  in  Koblenz,  Gennany,  7-8  October  2004 

•  A.  Tolk,  M.  Hieb,  K.  Galvin,  L.  Khimeche:  “Merging  National  Battle  Management 
Language  Initiatives  for  NATO  Projects” 

•  K.  Morse,  A.  Tolk,  M.  Pullen,  D.  Brutzman:  “XMSF  as  an  Enabler  for  NATO  M&S” 
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Presentation  during  the  Workshop  on  Distributed  Simulation  &  Virtual  Environments  at  the 
National  Technical  University  (NTU)  of  Singapore 

•  M.  Pullen:  “Web  Services  as  a  Mechanism  to  Integrate  Heterogeneous  Simulations  and 
C4I  Systems” 

•  A.  Tolk:  “M&S  Services  in  Operational  Service  Oriented  Architectures” 
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GLOSSARY  OF  TERMS  AND  ACRONYMS 


ACL 

AGIM 

AMSO 

ASD 

BCSE 

BPEL4WS 

C2IEDM 

C4I 

CINC 

CNAD 

CoABS 

COI 

COR 

CWM 

DAML 

DARPA 

DCEE 

DDM 

DIS 

DISA 

DMSO 

DoD 

DoDAF 

DON  CIO 

DTRA 

EA 

ERDC 

ES 

FAST 

FEC 

FEDEP 

FTE 

GES 

GIG 

GMU 

GSA 

HF 

HLA 

HTTP 

IEEE 

IETF 

IGMP 

I/ITSEC 


Access  Control  Language 
Aggregation  Interest  Management 
Army  Modeling  and  Simulation  Office 
Assistant  Secretary  of  Defense 

US  Army  Battle  Command,  Simulation  and  Experimentation  Directorate 
Business  Process  Execution  Language  for  Web  Services 
Command  and  Control  Infonnation  Exchange  Data  Model 
Command,  Control,  Communications,  Computers,  and  Intelligence 
Commander  in  Chief 

Conference  of  National  Armaments  Directors 

Control  of  Agent  Based  Systems 

Community  of  Interest 

Contracting  Officer’s  Representative 

Common  Warehouse  Metamodel 

DARPA  Agent  Markup  Language 

Defense  Advanced  Research  Projects  Agency 

Distributed  Continuous  Experimentation  Environment 

Data  Distribution  Management 

Distributed  Interactive  Simulation 

Defense  Information  Systems  Agency 

Defense  Modeling  and  Simulation  Office 

Department  of  Defense 

DoD  Architectural  Framework 

Department  of  the  Navy  Chief  Information  Officer 

Defense  Threat  Reduction  Agency 

Enterprise  Architecture 

US  Army  Engineer  Research  and  Development  Center 
Enterprise  Services 

Flexible  Asymmetric  Simulation  Technologies 

Forward  Error  Correction 

Federation  Development  and  Execution  Process 

Full-Time  Equivalent 

Grid  Enterprise  Services 

Global  Infonnation  Grid 

George  Mason  University 

General  Services  Administration 

Horizontal  Fusion 

High-Level  Architecture 

Hyper  Text  Transfer  Protocol 

Institute  of  Electrical  and  Electronics  Engineers 

Internet  Engineering  Task  Force 

Internet  Group  Management  Protocol 

Interservice/Industry  Training,  Simulation,  and  Education 

Conference 
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IP 

Intellectual  Property 

IPR 

In  Progress  Review 

ISO 

International  Standards  Organization 

IT 

Information  Technology 

JFCOM 

Joint  Forces  Command 

JTA 

Joint  Technical  Architecture 

M&S 

Modeling  and  Simulation 

MMF 

Mission-to-Means  Framework 

MOF 

Meta  Object  Facility 

MOOTW 

Military  Operations  Other  Than  War 

MOVES 

Modeling,  Virtual  Environments,  and  Simulation 

MPLS 

Multiprotocol  Label  Switching 

MST 

Minimum- weight  Spanning  Tree 

MTF 

Message  Text  Format 

NATO 

North  Atlantic  Treaty  Organization 

NC3A 

NATO  Consultation,  Command  and  Control  Agency 

NCCP 

Network  Centric  Capabilities  Pilot 

NCES 

Net-Centric  Enterprise  Services 

NEW 

Network  EducationWare 

NPS 

Naval  Postgraduate  School 

ODU 

Old  Dominion  University 

OGC 

Open  Geospatial  Consortium 

OIL 

Ontology  Inference  Layer 

OSD 

Office  of  the  Secretary  of  Defense 

OSI 

Open  System  Interconnection 

OWL 

Web  Ontology  Language 

PIM 

Platform  Independent  Model 

PKI 

Public  Key  Infrastructure 

PSM 

Platform  Specific  Model 

QoS 

Quality  of  Service 

RBAC 

Role  Based  Access  Control 

RDF 

Resource  Description  Framework 

RDF-S 

RDF  Schemas 

RF 

Radio  Frequency 

RT-DVS 

Real-Time  Distributed  Virtual  Simulation 

RTI 

Run-Time  Infrastructure 

SAIC 

Science  Applications  International  Corporation 

SGML 

Standard  Generalized  Markup  Language 

SISO 

Simulation  Interoperability  Standards  Organization 

SIW 

Simulation  Interoperability  Workshop 

SMART 

Simulation,  Modeling,  Acquisition,  Requirements,  and  Training 

SOA 

Service  Oriented  Architecture 

SOAP 

Simple  Object  Access  Protocol 

SOW 

Statement  of  Work 

SRMP 

Selectively  Reliable  Multicast  Protocol 

STF 

SEDRIS  Transmittal  Format 
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STRATCOM 

Strategic  Command 

TENA 

Test  and  Training  Enabling  Architecture 

UDDI 

Universal  Description,  Discovery,  and  Integration 

UML 

Unified  Modeling  Language 

VMASC 

Virginia  Modeling,  Analysis,  and  Simulation  Center 

W3C 

World  Wide  Web  Consortium 

WE-RTI 

Web-Enabled  RTI 

WSDL 

Web  Services  Description  Language 

WSIM 

Web  Services  Interest  Management 

XBML 

Extensible  Battle  Management  Language 

XC2I 

Experimentation  Command  and  Control  Interface 

XML 

Extensible  Markup  Language 

XMSF 

Extensible  Modeling  and  Simulation  Framework 

XOM 

XMSF  Overlay  Multicast 

XSLT 

Extensible  Stylesheet  Language  Transfonnations 

XTC 

XML-based  Tactical  Chat 
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